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AAS ial It 


在 过 去 单 核 CPU 时 代 ， 单 任务 在 一 个 时 间 点 只 能 执行 单一 程序 ， 
随 看 多 核 CPU 的 发 展 ， 并 行程 序 开发 殉 显 得 万 为 重要 。 


本 书 主要 介绍 基于 Java 的 并 行程 序 设 计 基 础 、 思 路 、 方 法 和 实 
战 。 第 一 ， 了 立足 于 并 发 程序 基础 ， 详 细 介 绍 Java 中 进行 并 行程 序 设计 
的 基本 方法 。 第 二 ， 进 一 步 详细 介绍 JDK 中 对 并 行程 序 的 强大 文 持 ， 
帮助 读者 快速 、 稳 健 地 进行 并 行程 序 开发 。 第 三 ， 详 细 讨 论 有 
天 “ 锁 ” 的 优化 和 提高 并 行程 序 性 能 级 别 的 方法 和 思路 。 第 四 ， 介 绍 并 
行 的 基本 设计 模式 及 Java 8 对 并 行程 序 的 文 持 和 改进 。 第 五 ， 介 绍 高 并 
发 框架 Akka 的 使 用 方法 。 最 后 ， 详 细 介 绍 并 行程 序 的 调试 方法 。 


本 书 内 容 丰 富 ， 实 例 典 型 ， 实 用 性 强 ， 适 合 有 一 定 Java 基 础 的 技 
术 开 发 人 员 阅 读 。 
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关于 Java 与 并 行 


由 于 单 核 CPU 的 主 频 逐 步 逼 近 极 限 ， 多 核 CPU 以 构成 为 了 一 种 必 
然 的 技术 趋势 。 所 以 ， 多 线程 并 行程 序 便 显得 越 来 越 重要 。 并 行 计算 
的 一 个 重要 应 用 场景 束 是 服务 端 编程 。 可 以 看 到 ， 目 前 服务 羔 CPU 的 
核心 数 已 经 轻松 超越 10 核 心 ， 而 Java 显 然 已 经 成 为 当下 最 流行 的 服务 
端 编 程 语言 ， 因 此 熟悉 和 了 解 基 于 Java 的 并 行程 序 开发 有 着 重要 的 实 
用 价值 。 


本 书 的 体系 结构 


本 书 立 足 于 实际 开发 ， 又 不 缺乏 理论 介绍 ， 力 求 通俗 易 懂 、 循 序 
渐进 。 本 书 共 分 为 8 章 。 


第 1 章 主要 介绍 了 并 行 计 算 中 相关 的 一 些 基 本 概念 ， 树 立 读者 对 并 
行 计算 的 基本 认识 ; 介绍 了 两 个 重要 的 并 行 性 能 评估 定律 ， 以 及 Java 
内 存 模型 IMM ° 


第 2 章 介 绍 了 Java 并 行程 序 开发 的 基础 ， 包 括 Java 中 Thread 的 基本 
使 用 方法 等 ， 也 详细 介绍 了 并 行程 序 容 易 引 发 的 一 些 销 误 和 误 用 。 


第 3 章 介 绍 了 JDK 内 部 对 并 行程 序 开发 的 支持 ， 主 要 介绍 JUC 
(Java.util.concurrent) 中 一 些 工 具 的 使 用 方法 、 各 自 特点 及 它们 的 内 
部 实现 原理 。 


第 4 章 介绍 了 在 开发 过 程 中 可 以 进行 的 对 锁 的 优化 ， 也 进一步 简要 
描述 了 Java 虚 拟 机 层面 对 并 行程 序 的 优化 支持 。 此 外 ， 还 花费 一 定 篇 
幅 介 绍 了 有 关 无 锁 的 计算 。 


第 5 章 介 绍 了 并 行程 序 设计 中 常见 的 一 些 设计 模式 以 及 一 些 典型 的 
并 行 算法 和 使 用 方法 ， 其 中 包括 重要 的 Java NIO 和 AIO 的 介绍 


第 6 章 介 绍 了 Java 8 中 为 并 行 计算 做 的 新 的 改进 ， 包 括 并 行 流 、 
CompletableFuture、StampedLock 和 LongAdder ° 


第 7 章 主 要 介绍 了 高 并 发 框架 Akka 的 基本 使 用 方法 ， 并 使 用 Akka 
框架 实现 了 一 个 简单 的 粒子 群 算法 ， 模 拟 超 高 并 发 的 场景 。 


第 8 章 介 绍 了 使 用 Eclipse 进行 多 线程 调试 的 方法 ， 并 演示 了 通 
Ealipse 进 行 多 线程 调试 重 现 AmrayList 的 线程 不 \ 安 全 问题 。 


本 书 特色 


本 书 的 主要 特点 如 下 。 


1. 结构 清晰 。 本 书 一 共 8 章 ， 总 体 上 循序 渐进 ， 逐 步 提升 。 每 一 
都 各 目 有 鲜明 的 侧重 点 ， 有 利于 读者 快速 抓 住 重 点 。 

2. 理论 结合 实战 。 本 书 注重 实战 ， 书 中 重要 的 知识 点 都 安排 了 代 
码 实例 ， 帮 助 读者 理解 。 同 时 也 不 起 记 对 系统 的 内 部 实现 原理 


进行 深度 剖析 ° 

3. 通俗 易 懂 。 本 书 尽 量 避 免 采 用 过 于 理论 的 描述 方式 ， 简 单 的 白 
话 文风 格 贯 罕 全 书 ， 配 图 基本 上 为 手工 绘制 ， 降 低 了 理解 难 
度 ， 并 尽量 做 到 读者 在 阅读 过 程 中 少 下 点 、 无 育 点 。 


适合 阅读 人 群 


虽然 本 书 力求 通俗， 但 要 通读 本 书 并 取得 展 好 的 学 习 效 果 ， 要 求 
读者 需要 具备 基本 的 Java 知 识 或 者 一 定 的 编程 经 验 。 因此， 本 书 适 合 
以 下 读者 : 


拥有 一 定 开发 经 验 的 Java 平 台 开 发 人 员 (Java ` Scala ` JRuby 
等 ) 

软件 设计 师 、 架 构 师 

。 系统 调 优 人 员 

。 有 一 定 的 Java 编 程 基础 并 希望 进一步 加 深 对 并 行 的 理解 的 研发 


本 书 的 约定 


本 书 在 叙述 过 程 中 ， 有 如 下 约定 : 


。 本 书 中 所 述 的 JDK 1.5、JDK 1.6、JDK 1.7 ` JDK 1.8 分 别 等 同 于 
JDK 5 ` JDK 6 ` JDK 7 ` JDK 8 ° 
。 如 无 特殊 说 明 ， 本 书 的 程序 、 示 例 均 在 JDK 1.7 环 境 中 运行 。 


联系 作者 


本 书 的 写作 过 程 远 比 我 想象 得 更 艰 痒 ， 为 了 让 全 书 能 够 更 清楚 、 
更 正确 地 表达 和 论述 ， 我 经 历 了 很 多 个 不 眠 之 夜 ， 即 使 现在 回想 起 
来 ， 我 也 息 不 住 会 打 个 寒战 。 由 于 写作 水 平 的 限制 ， 书 中 难免 会 有 不 
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为 此 ， 如 果 读 者 有 任何 疑问 或 者 建议 ， 非 常 欢迎 大 家 加 入 QQ 群 
397196583， 一 起 探讨 学 习 中 的 困难 、 分 享 学 习 的 经 验 ， 我 期 竺 与 大 家 
一 起 交流 、 共 同 进 步 。 同 时 ， 也 希望 大 家 可 以 关注 我 的 博客 
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第 1 章 ” 走 入 并 行 世界 


当 你 打开 本 书 ， 也 许 你 正 试图 将 你 的 应 用 改造 成 并 行 模式 运行 ， 
也 许 你 只 是 单纯 地 对 并 行程 序 感 兴趣 。 无 论 出 于 何 种 原因 ， 你 正 对 并 
行 计算 充满 好 奇 、 疑 问 和 求知 欲 。 如 采 是 这 样 ， 那 整 对 了 ， 市 着 你 的 
好 奇 和 疑问 ， 让 我 们 一 起 邀 游 并 行程 序 的 世界 ， 深 入 了 解 它们 究竟 是 
如 何 工作 的 吧 ! 


不 过 首先 ， 我 想 要 公布 一 条 令 人 泪 汉 的 消 轧 。 束 在 大 伙 儿 都 认为 
并 行 计算 必然 成 为 未 来 的 大 趋势 时 ，2014 年 底 ， Avoiding ping pong 论 
坛 上 ， 伟 大 的 Linus Torvalds 提 出 了 一 个 截然 不 同 的 观点 ， 他 说 :“ 起 掉 
那 该 死 的 并 行 吧 ! ”( 原 文 : Give it up. The whole "parallel computing is 


the future" is a bunch of crock. ) 


1.1 何去何从 的 并 行 计算 


到 改 我 们 该 如 何 选 择 呢 ? 本 节 的 目的 就 古 拨 云 见 日 。 


1.1.1 起 掉 那 该 死 的 并 行 


Linus Torvalds 是 一 个 传奇 式 的 人 物 (图 1.1) ， 是 他 给 出 了 Linux 
的 原型 ， 并 一 直 致 力 于 推广 和 发 展 Linux 系 统 。 他 在 1991 年 首先 在 网 络 
上 发 布 了 Linux 源 码 ， 从 此 一 发 而 不 可 收 。Linux 迅 速 崛 起 壮大 ， 成 为 
目前 使 用 最 广泛 的 操作 系统 之 一 


图 1-1 传奇 的 Linus Torvalds 


自 2002 年 起 ，Linus 束 决定 使 用 BitKeeper 作 为 Linux 内 核 开 发 的 版 
本 控制 工具 ， 以 此 来 维护 Linux 的 内 核 源码 。BitKeeper 是 一 大 分 布 式 版 
本 控制 软件 ， 它 是 一 套 商用 系统 ， 由 BitMover 公 司 开 发 。2005 年 ， 
BitKeeper 宣 称 发 现 Linux 内 核 开 发 人 员 使 用 逆 癌 工程 来 试图 解析 
BitKeeper 内 部 协议 。 因 此 ， 决 定 癌 Linus 收 回 BitKeeper 授 权 。 尺 管 
Linux 核 心 团 队 与 BitMover 公 司 进 行 了 协商 ， 但 是 无 法 解决 他 们 之 间 的 
分 歧 。 因 此 ，Linus 决 定 上 自行 研发 版 本 控制 工具 来 代 奉 BitKeeper。 于 
Æ, GIET ° 


如 果 大 家 正在 使 用 Git， 我 相信 你 们 一 定 会 被 Git 的 魅力 所 折服 ， 
如 采 还 没有 了 解 过 Git， 那 么 我 强烈 建议 你 去 关注 一 下 这 于 优秀 的 产 
品 o 

而 正 是 这 位 传奇 人 物 ， 给 目前 红 红 火 火 的 并 行 计算 浅 了 一 大 盆 冷 
水 。 那 么 ， 并 行 计 算 完 竟 应 该 何去何从 呢 ? 


在 Linus 的 发 言 中 这 人 么 说 道 : 


Where the hell do you envision that those magical parallel algorithms 


would be used? 


The only place where parallelism matters is in graphics or on the 
server side, where we already largely have it. Pushing it anywhere else is 


just pointless. 


fa eB SL Ay AHA ART A Be Se HAT TY A ZS? 


并 行 计算 只 有 在 图 像 处 理 和 服务 端 编程 2 个 领域 可 以 使 用 ， 并 且 它 
在 这 2 个 领域 确实 有 着 大 量 广泛 的 使 用 。 但 是 在 其 他 任何 地 方 ， 并 行 计 


算 坚 无 建树 ! 


So the whole argument that people should parallelize their code is 
fundamentally flawed. It rests on incorrect assumptions. It's a fad that has 


been going on too long. 


因此 ， 人 们 在 争论 是 否 应 该 将 他 们 的 代码 并 行 化 是 一 个 本 质 上 的 
错误 。 这 完全 就 基于 一 个 错误 的 假设 。“ 并 行 " 是 一 个 早 该 结束 的 时 小 
用 语 。 


看 了 这 上 段 较 为 完整 的 表述 ， 大 家 应 该 对 Linus 的 观点 有 所 感触 ， 我 
对 此 也 表示 赞同 。 与 串 行 程序 不 同 ， 并 行程 序 的 设计 和 实现 异 肖 复 
杂 ， 不 仅仅 体现 在 程序 的 功能 分 离 上 ， 多 线程 间 的 协调 性 、 乱 序 性 都 
会 成 为 程序 正确 执行 的 障碍 。 只 要 你 稍 不 留神 ， 束 会 失 之 台 硅 ， 雇 以 
FPE! 混乱 的 程序 难以 阅读 、 难 以 理解 ， 更 难以 调试 。 所 谓 并 行 ， 也 
忠 是 把 简单 问题 复杂 化 的 典型 。 因 此 ， 只 有 “ 闫 子 ” 才 会 叫嚣 并 行 束 是 


未 来 (the crazies talking about scaling to hundreds of cores are just that - 


crazy) ° 
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可 以 、 也 需要 使 用 并 行 技术 的 。 仔 细 想 想 ， 为 什么 图 像 处 理 和 服务 端 
程序 是 特例 呢 ? 


和 用 户 终端 程序 不 同 ， 图 像 处 理 往 往 拥 有 极 大 的 计算 量 。 一 张 
1024x768 像 素 的 图 片 ， 包 含 多 达 78 万 6 千 多 个 像素 。 即 使 将 所 有 的 像 
素 遍 历 一 迄 ， 也 得 伦 不 少时 间 。 更 何况 ， 图 像 处 理 涉及 大 量 的 矩阵 计 
算 。 和 矩阵 的 规模 和 数量 都 会 非常 大 。 面 对 如 此 密集 的 计算 ， 很 有 可 能 
超过 单 核 CPU 的 计算 能 力 ， 所 以 目 然 需要 引入 多 核 计 算 了 。 


而 服务 端 程序 与 一 般 的 用 户 终端 程序 相 比 ， 一 方面 ， 服 务 端 程序 
需要 承受 很 重 的 用 户 访 问 压力 。 根 据 淘宝 的 数据 ， 它 在 “ 双 十 一 ”一 
天 ， 文 付 宝 核心 数据 库 集群 处 理 了 41 亿 个 事务 ， 执 行 285 亿 次 SQL， 生 
成 15TB 日 志 ， 访 问 1931 亿 次 内 存 数据 块 ，13 亿 个 物理 读 。 如 此 密集 的 
访问 ， 和 恐 人 任何 一 台 单 机 都 难以 胜任 ， 因 此 ， 并 行程 序 也 就 自然 成 了 
唯一 的 出 路 。 另 一 方面 ， 服 务 端 程序 往往 会 比 用 户 终 端 程序 拥有 更 复 
杂 的 业务 模型 。 面 对 复杂 业务 模型 ， 并 行程 序 会 比 串 行程 序 更 容易 适 
应 业务 需求 ， 更 容易 模拟 我 们 的 现实 世界 。 毕 竟 ， 我 们 的 世界 本 质 上 
是 并 行 的 。 比 如 ， 当 你 开 开 心心 去 上 学 的 上 时候， 妈妈 可 能 在 家 里 忙 着 
家 务 ， 和 爸爸 在 外 打工 赚钱 ， 一 家 人 其 乐 融融 。 如 果 有 一 天 ， 你 需要 使 
用 你 的 计算 机 来 模拟 这 个 场景 ， 你 会 怎么 做 呢 ? 如 果 你 就 在 一 个 线程 
里 ， 既 做 了 你 自己 ， 又 做 了 妈妈 ， 又 做 了 爸爸， 显然 这 不 是 一 种 好 的 
解决 方案 。 但 如 果 你 使 用 三 个 线程 ， 分 别 模 拟 这 三 个 人 ， 一 切 看 起 来 
又 是 那么 自然 ， 而 且 容 易 被 人 理解 。 


再 举 一 个 专业 点 的 例子 ， 比 如 基础 平台 Java 虚 拟 机 ， 虚 拟 机 除了 
要 执行 main 函 数 主 线程 外 ， 还 需要 做 JIT 编 译 ， 需 要 做 垃圾 回收 。 无 论 
征 main 团 数 、JIT 编 译 还 是 垃圾 回收 ， 在 虚拟 机 内 部 都 实现 为 单独 的 一 
个 线程 。 征 什么 使 得 虚拟 机 的 研发 人 员 这 么 做 呢 ? 显然 ， 这 是 因为 建 
模 的 需要 。 因 为 这 里 的 每 一 个 任务 都 是 相 对 独立 的 。 我 们 不 应 该 将 没 
有 关联 的 业务 代码 拼凑 在 一 起 ， 分 离 为 不 同 的 线程 更 容易 理解 和 维 
护 。 因 此 ， 使 用 并 行 也 不 完全 出 目 性 能 的 考虑 ， 而 有 时 候 ， 我 们 会 很 
目 然 地 那么 做 。 


1.1.2 可怕 的 现实 摩尔 定律 的 失效 


摩尔 定律 是 由 英特尔 创始 人 之 一 戈 登 .摩尔 提出 来 的 。 其 内 容 为 ， 
集成 电路 上 可 容纳 的 电 晶体 (晶体管 ) 数目 ， 约 每 隔 24 个 月 便 会 增加 
一 倍 ， 经 常 被 引用 的 “18 个 月 *， 是 由 英特尔 首席 执行 官 大 卫 . 豪 斯 所 
说 ， 预 计 18 个 月 会 将 芯片 的 性 能 提高 一 倍 ( 即 更 多 的 晶体 管 使 其 更 
快 ) 。 


说 得 直 白 点 ， 就 是 每 18 个 月 到 24 个 月 ， 我 们 的 计算 机 性 能 就 能 翻 
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反 过 来 说 ， 就 是 每 过 18 个 月 到 24 个 月 ， 你 在 未 来 用 一 半 的 价钱 就 
能 买 到 和 现在 性 能 相同 的 计算 设备 了 。 这 听 起 来 是 一 件 多 么 激 动人 心 
的 事情 呀 ! 


但 是 ， 麻 尔 定律 并 不 是 一 种 自然 法 则 或 者 物理 定律 ， 它 只 是 基于 
人 为 观测 数据 后 ， 对 未 来 的 预测 。 按 照 这 种 速度 ， 我 们 的 计算 能 力 将 
会 按照 指数 速度 增长 ， 用 不 了 多 久 ， 我 们 的 计算 能 力 就 能 超越 < 上 
IWT! 畅想 未 来 ， 基 于 强劲 的 超级 计算 机 ， 我 们 甚至 可 以 模拟 整个 宇 
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摩尔 定律 的 有 效 性 已 经 超过 半 个 世纪 了 ， 然 而 ， 在 2004 年 ，Intel 
宣布 将 4GHz 心 片 的 发 布 时 间 推 迟到 2005 年 ， 在 2004 年 秋季 ，Intel 宣 布 
彻底 取消 4GHz 计 划 (图 1.2) 。 


图 1.2 Intel CEO Barret 单 膝下 跪 对 取消 4GHz 感 到 抱歉 


征 什么 迫使 世界 顶级 的 科技 巨头 放弃 4GHz 的 研发 呢 ? TA, A 
前 的 硅 电 路 而 言 ， 很 有 可 能 已 经 走 到 了 头 。 我 们 的 制造 工艺 已 经 到 了 
纳米 了 。1 纳 米 是 103 米 ， 也 就 是 10 亿 分 之 一 米 。 这 已 经 是 一 个 相当 小 
的 数 子 了 。 殊 目前 的 科技 术 平 而 言 ， 如 琳 无 法 在 物质 分 子 层面 以 下 进 
行 工 作 ， 那 么 也 许 4GHz 的 芯片 就 已 经 接近 了 理论 极限 。 因 为 即使 一 个 
水 分 子 ， 它 的 直径 也 有 0.4 纳 米 。 再 往 下 发 展 束 显得 有 些 困 难 。 当 然 ， 
如 果 我 们 使 用 完全 不 同 的 计算 理论 或 者 发 片 生产 工艺 ， 也 许 会 有 本 质 
的 突破 ， 但 目前 还 没有 看 到 这 种 技术 被 大 规模 使 用 的 可 能 。 


因此 ， 摩 尔 定律 在 CPU 的 计算 性 能 上 可 能 已 经 失效 。 虽 然 ， 现 在 
Intel 已 经 研制 出 了 4GHz 心 片 ， 但 可 以 看 到 ， 在 近 10 年 的 发 展 中 ，CPU 
主 频 的 提升 已 经 明显 遇 到 了 一 些 暂时 不 可 造 越 的 瓶 领 。 


1.1.3 ”柳暗花明 : 不 断 地 前 进 


虽然 CPU 的 性 能 已 经 几 近 止步 ， 长 达 半 个 世纪 的 摩尔 定律 爱 然 倒 
地 。 但 是 这 依然 没有 阻挡 科学 家 和 工程 师 们 带领 我 们 不 断 问 前 的 脚 
IE 0 


从 2005 年 开始 ， 我 们 已 经 不 再 追求 单 核 的 计算 速度 ， 而 着 迷 于 研 
究 如 何 将 多 个 独立 的 计算 单元 整合 到 单独 的 CPU 中 ， 也 就 是 我 们 所 说 
的 多 核 CPU。 短 短 十 几 年 的 发 展 ， 家 用 型 CPU， 比 如 Intel i7 就 可 以 拥 
有 4 核心 ， 甚 至 8 核心 。 而 专业 服务 器 则 通常 可 以 配 有 几 个 独立 的 
CPU， 每 一 个 CPU 都 拥有 多 达 8 个 甚至 更 多 的 内 核 。 从 整体 上 看 ， 专 业 
服务 器 的 内 核 总 数 甚 至 可 以 达到 几 百 个 。 


非常 令 人 激动 ， 摩 尔 定 律 在 另外 一 个 侧面 又 生效 了 。 根 据 这 个 定 
律 ， 我 们 可 以 预测 ， 每 过 18 到 24 个 月 ，CPU 的 核心 数 束 会 翻 一 番 。 用 
不 了 多 久 ， 拥 有 几 十 甚至 上 百 CPU 内 核 的 芯片 就 能 进入 千家 万 户 。 


顶级 计算 机 科学 家 唐纳德 : 尔 文 : 克 努 斯 (Donald Ervin Knuth) , 
如 此 评价 这 种 情况 : 在 我 看 来 ， 这 种 现象 (并发) 或 多 或 少 是 由 于 硬 
件 设 计 者 已 经 无 计 可 施 了 导致 的 ， 他 们 将 摩尔 定律 失效 的 责任 推脱 给 
软件 开发 者 。 


唐纳德 (图 1.3) 和 是 著 名 计算 机 巨著 《计算 机 程序 设计 忆 术 》 的 作 
者 。《 美 国 科学 家 》 杂 志 曾 将 该 书 与 爱 因 斯 坦 的 《相对 论 》， 狄 拉 死 
的 《量子 力学 》 和 理 查 - 费 曼 的 《量子 电动 力学 》 等 书 并 列 为 20 世 纪 最 
重要 的 12 本 物理 科学 类 专 论 书 之 一 。 


图 1.3 ”唐纳德 院士 


1.1.4 光明 或 是 黑暗 


根据 唐纳德 的 观点 ， 摩 尔 定律 本 应 该 由 硬件 开发 人 员 维 持 。 但 
和 是， 很 不 笠 ， 硬 件 工程 师 似乎 已 经 无 计 可 施 了 。 为 了 继续 保持 性 能 的 
高 速 发 展 ， 硬 件 工程 师 束 破 天 蕊 地 想 出 了 将 多 个 CPU 内 核 塞 进 一 个 
CPU 里 的 奇妙 想法 。 由 此 ， 并 行 计 算 吏 被 非常 目 然 地 推广 开 来 ， 而 随 
之 而 来 的 问题 也 层出不穷 ， 程 序 员 的 黑暗 时 期 也 随 之 到 来 。 简 化 的 硬 
件 设 计 方 案 必 然 帝 来 软件 设计 的 复杂 性 。 换 句 话 说， 软件 工程 师 正在 
为 硬件 工程 师 无 法 完成 的 工作 负责 ， 因 此 ， 也 残 有 了 唐纳德 的 “他 们 将 
摩尔 定律 失效 的 责任 推脱 给 了 软件 开发 者 ”的 说 法 。 


所 以 ， 如 何 让 多 个 CPU 有 效 并 且 正 确 地 工作 也 就 成 为 了 一 门 技 
术 ， 甚 至 是 很 大 的 学 问 。 比 如 ， 多 线程 间 如 何 保证 线程 安全 ， 如 何 正 


确 理解 线程 间 的 无 序 性 、 可 见 性 ， 如 何 尽 可 能 提高 并 行程 序 的 设计 ， 
又 如 何 将 串 行 程序 改造 为 并 行程 序 。 而 对 并 行 计算 的 研究 ， 也 就 古 希 
望 在 这 片 黑暗 中 市 来 光明 。 


12 ”你 必须 知道 的 几 个 概念 


现在 ， 并 行 计 算 显然 已 经 成 为 一 门 正 式 的 学 问 。 也 许 很 多 人 ( 包 
括 Linus 在 内 ) ， 都 会 觉得 并 行 计算 或 者 说 并 行 算法 是 多 么 奇 栈 。 但 现 
在 我 们 也 不 得 不 承认 ， 在 某 些 领域 ,这 些 算法 还 是 有 用 武之 地 的 。 既 
然 说 服务 端 编 程 还 吓 大 量 需 要 并 行 计算 的 ， 而 Java 也 主要 占领 者 服务 
端 市 场 ， 那 么 对 Java 的 并 行 计算 的 研究 也 就 显得 非常 的 必要 。 但 首 
先 ， 我 想 在 这 里 先 介绍 几 个 重要 的 相关 概念 。 


121 同步 ( Synchronous ) 和 异步 


(Asynchronous 


同步 和 异步 通常 用 来 形容 一 次 方法 调用 。 同 步 方法 调用 一 旦 开 
始 ， 调 用 者 必须 等 到 方法 调用 返回 后 ， 才 能 继续 后 续 的 行为 。 异 步 方 
法 调用 更 像 一 个 消 妃 传递 ， 一 旦 开始 ， 方 法 调用 吏 会 立即 返回 ， 调 用 
者 整 可 以 继续 后 续 的 操作 。 而 异步 方法 通 肖 会 在 男 外 一 个 线程 中 “ 真 
实 ” 地 执行 。 整 个 过 程 ， 不 会 阻碍 调用 者 的 工作 。 图 1.4 显 示 了 同步 方 
法 调用 和 有 异步 方法 调用 的 区 别 。 对 于 调用 者 来 说 ， 异 步调 用 似乎 是 一 
瞬间 驶 完 成 的 。 如 采 异 步调 用 需要 返回 结 末 ， 那 么 当 这 个 异步 调用 真 
实 完成 时 ， 则 会 通知 调用 者 。 
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图 1.4 ”同步 和 异步 方法 调用 


打 个 比方 ， 比 如 我 们 去 购物 ， 如 果 你 去 商场 实体 店 严 一 台 空 调 ， 
当 你 到 了 商场 看 中 了 一 款 空 调 ， 你 束 想 售货员 下 单 。 和 售货员 去 仓库 帮 
你 调配 物品 。 这 天 你 热 得 实在 不 行 了 ， 束 俊 着 两 家 赶紧 给 你 送 货 ， 于 
苹 你 忠 等 在 商店 里 ， 候 着 他 们 ， 直 到 商家 把 你 和 空调 一 起 送 回 家 ， 一 
次 恰 快 的 购物 束 结 束 了 。 这 束 古 同步 调用 。 


不 过 ， 如 果 我 们 赶 时 晓 ， 就 坐 在 家 里 打开 电脑 ， 在 网 上 订购 了 一 
台 空 调 。 当 你 完成 网 上 支付 的 时 候 ， 对 你 来 说 购物 过 程 已 经 结束 了 。 
虽然 空调 还 没 送 到 家 ， 但 是 你 的 任务 都 已 经 完成 了 。 商家 接 到 了 你 的 
订单 后 ， 束 会 加 紧 安 排 送 货 ， 当 然 这 一 切 已 经 跟 你 无 天 了 。 你 已 经 文 
付 完 成 ， 想 干什么 束 能 去 干什么 ， 出 去 溜 几 图 都 不 成 问题 ， 等 送 货 
门 的 时 候 ， 接 到 商家 的 电话 ， 回 家 一 趋 签收 就 完事 了 。 这 束 古 异步 调 
用 。 


122 并 发 (Concurrency ) 和 并 行 


(Parallelism) 


并 发 和 并 行 是 两 个 非常 容易 被 温 清 的 概念 。 它 们 都 可 以 表示 两 个 
或 者 多 个 任务 一 起 执行 ， 但 是 偏重 点 有 些 不 同 。 并 发 仿 重 于 多 个 任务 
交 蔡 执行 ， 而 多 个 任务 之 间 有 可 能 还 是 串 行 的 。 而 并 行 是 真正 意义 上 
的 “同时 执行 ”。 图 1.5 很 好 地 诠释 了 这 点 。 


好 
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图 1.5 ”并 发 和 并 行 


疗 格 意义 上 来 说 ， 并 行 的 多 个 任务 是 真实 的 同时 执行 ， 而 对 于 并 
发 来 说 ， 这 个 过 程 只 古 交 替 的 ， 一 会 儿 运 行 任务 A 一 会 儿 执 行 任务 B， 
系统 会 不 集 地 在 两 者 间 切 换 。 但 对 于 外 部 观察 者 来 说 ， 即 使 多 个 任务 
之 间 征 串 行 并 发 的 ， 也 会 造成 多 任务 间 是 并 行 执行 的 错觉 。 


这 两 种 情况 在 生活 中 都 很 常见 。 我 曾经 去 黄山 旅游 过 两 次 ， 黄 山 
风景 奇特 ， 有 着 “五 后 归来 不 看 山 ， 黄 山 归 来 不 看 后” 的 美称 。 只 要 去 
过 黄山 的 人 都 应 该 知道 ， 导 游 时 党 挂 在 嘴 边 的 “走路 不 看 景 ， 看 景 不 走 
路 ”。 因 为 黄山 项 上 经 党 下 雨 ， 地 面 湿 消 ， 地 形 险峻 。 如 采 边 走边 看 ， 
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发 ”。 它 和 “ 边 走边 看 "有 着 非 常 奇 妙 的 关系 ， 因 为 这 两 种 情况 ， 都 可 以 
被 认 为 是 “同时 在 看 景 和 走路 ”。 


那么 在 黄山 上 真正 的 “并 行 ?应 该 是 什么 样子 呢 ? 聪明 的 同学 应 该 
可 以 想到 ， 那 惑 是 坐 弧 车 上 山 。 缆 车 可 以 代 符 步行 ， 你 坐 在 线 车 上 才 
能 专心 欣 偶 沿途 的 风景 ,“ 走 路 ”这些 事情 全 部 交 给 缆车 去 完成 陇 好 
ye 


实际 上 ， 如 果 系 统 内 只 有 一 个 CPU， 而 使 用 多 进程 或 者 多 线程 任 
务 ， 那 么 真实 环境 中 这 些 任务 不 可 能 是 真实 并 行 的 ， 毕 竟 一 个 CPU 一 
次 只 能 执行 一 条 指令 ， 这 种 情况 下 多 进程 或 者 多 线程 就 是 并 发 的 ， 而 
不 是 并 行 的 (操作 系统 会 不 停 切 换 多 个 任务 ) 。 真 实 的 并 行 也 只 可 能 
出 现在 拥有 多 个 CPU 的 系统 中 (比如 多 核 CPU) 。 

由 于 并 发 的 最 终 效 果 可 能 是 和 并 行 一 样 的 ， 因 此 ， 如 果 没 有 特别 
的 需要 ， 我 在 本 书 中 不 会 特别 强调 两 者 的 区 别 。 


1.2.3 ”临界 区 


临界 区 用 来 表示 一 种 公共 资源 或 者 说 是 共 至 数据 ， 可 以 被 多 个 线 
程 使 用 。 但 是 每 一 次 ， 只 能 有 一 个 线程 使 用 它 ， 一 旦 临界 区 资源 被 占 
用 ， 其 他 线程 要 想 使 用 这 个 资源 ， 就 必须 等 待 。 


比如 ， 在 一 个 办 公 室 里 有 一 人 台 打 印 机 。 打 印 机 一 次 只 能 执行 一 个 
任务 。 如 采 小 王 和 小 明 同时 需要 打印 文件 ， 很 显然 ， 如 果 小 王爷 下 发 
了 打印 任务 ， 打 印 机 束 开 始 打印 小 王 的 文件 。 小 明 的 任务 惑 只 能 等 待 
小 王 打印 结束 后 才能 打印 。 这 里 的 打印 机 束 是 一 个 临界 区 的 例子 。 


在 并 行程 序 中 ， 临 界 区 资源 是 保护 的 对 象 ， 如 果 意 外 出 现 打印 机 
同时 执行 两 个 打印 任务 ， 那 么 最 可 能 的 结 末 束 是 打印 出 来 的 文件 束 会 


征 损坏 的 文件 。 它 既 不 是 小 王 想 要 的 ， 也 不 是 小 明 想 要 的 。 


1.2.4 阻塞 (Blocking) 和 非 阻 塞 
(Non-Blocking) 


阻塞 和 非 阻塞 通 间 用 来 形容 多 线程 间 的 相互 影响 。 比 如 一 个 线程 
占用 了 临界 区 资源 ， 那 么 其 他 所 有 需要 这 个 资源 的 线程 整 必须 在 这 个 
临界 区 中 进行 等 待 。 等 待 会 导致 线程 挂 起， 这 种 情况 吏 征 阻塞 。 此 
时 ， 如 果 占 用 资源 的 线程 一 直 不 愿意 释放 资源 ， 那 么 其 他 所 有 阻塞 在 
这 个 临界 区 上 的 线程 都 不 能 工作 。 


非 阻 塞 的 意思 与 之 相反 ， 它 强调 没有 一 个 线程 可 以 妨碍 其 他 线程 
执行 。 所 有 的 线程 都 会 答 试 不 断 前 问 执 行 。 有 关 这 个 概念 ， 将 在 本 
章 “ 并 发 级 别 ” 一 节 中 做 更 详细 的 描述 。 


1.2.5 XÆ Bi (Deadlock) ` DLR 
(Starvation) 和 活 锁 (Livelock) 


Se > QURAN ABB TS AREA TR ATE ala o MOR AC HWE tt 
RTBU, ALAM RASH] REMAN, tee BT Be ie ME HS Se 
TATT ° 


和 死 锁 应 该 是 最 糟糕 的 一 种 情况 了 (当然 ， 其 他 几 种 情况 也 好 不 到 
BES) ， 图 1.6 显 示 了 一 个 死 锁 的 发 生 。 


图 1.6” 死 锁 的 发 生 


A、`B、C、D 四 辆 小 车 在 这 种 情况 下 都 无 法 继续 行 台 了 。 它 们 彼 
此 之 间 相 互 占用 了 其 他 车 辆 的 车 道 ， 如 条 大 家 都 不 愿意 释放 目 己 的 车 
道 ， 那 么 这 个 状态 将 永远 维持 下 去 ， 谁 都 不 可 能 通过 。 和 死 锁 是 一 个 很 
严重 的 ， 并 且 应 该 避免 和 时 时 小 心 的 问题 ， 我 们 将 安排 在 “ 锁 的 优化 与 
注意 事项 ”一 章 中 进行 更 详细 的 讨论 。 


饥 俄 是 指 某 一 个 或 者 多 个 线程 因为 种 种 原因 无 法 获得 所 需要 的 资 
源 ， 导 致 一 直 无 法 执行 。 比 如 它 的 线程 优先 级 可 能 太 低 ， 而 高 优先 级 
的 线程 不 断 抢占 它 需 要 的 资源 ， 导 致 低 优 先 级 线程 元 法 工作 。 在 目 然 
界 中 ， 母 乌 喂 食 锥 乌 时 ， 很 容易 出 现 这 种 情况 。 由 于 锥 乌 很 多 ， 食 物 
可 能 有 限 ， 积 马 之 间 的 食物 竞争 可 能 非常 厉害 ， 小 委 乌 因为 经 党 抢 不 
到 食物 ， 有 可 能 会 被 饿 死 。 线 程 的 饥饿 也 非常 类 似 这 种 情况 。 另 外 一 
种 可 能 是 ， 某 一 个 线程 一 直 占 着 关键 资源 不 放 ， 导 致 其 他 需要 这 个 资 
源 的 线程 无 法 正常 执行 ， 这 种 情况 也 是 饥饿 的 一 种 。 与 死 锁 相 比 ， 饥 


场 还 是 有 可 能 在 未 来 一 段 时 间 内 解决 的 《比如 高 优 移 级 的 线程 已 经 完 
成 任务 ,不 再 疯狂 的 执行 ° 


活 锁定 一 种 非常 有 趣 的 情况 。 不 知道 大 家 是 不 是 有 过 到 过 这 人 么 一 
种 场景 ， 当 你 要 坐 电 樟 下 楼 ， 电 梯 到 了 ， 门 开 了 ， 这 时 你 正 准备 出 
去 。 但 很 不 巧 的 是 ， 门 外 一 个 人 接着 你 的 去 路 ， 他 想 进 来 。 于 是 ， 你 
很 绅士 地 靠 左 走 ， 避 让 对 方 。 同 时 ， 对 方 也 是 非常 绅士 地 ， 但 他 靠 右 
走 希 望 避让 你 。 结 果 ， 你 们 俩 束 又 撞 上 了 。 于 是 乎 ， 你 们 都 意识 到 了 
问题 ， 布 望 尽快 避让 对 方 ， 你 立即 向 右边 走 ， 同 时 ， 他 立即 同 左 边 
E o ER, MEET! 不 过 介 于 人 类 的 智能 ， 我 相信 这 个 动作 重复 2、 
3 次 后 ， 你 应 该 可 以 顺利 解决 这 个 问题 。 因 为 这 个 时 候 ， 大 家 都 会 本 能 
的 对 视 ， 进 行 交 流 ， 保 证 这 种 情况 不 再 发 生 。 


但 如 采 这 种 情况 发 生 在 两 个 线程 间 可 能 束 不 会 那么 幸运 了 。 如果 
线程 的 智力 不 够 ， 且 都 秉承 着 “谦让 ”的 原则 ， 主 动 将 资源 释放 给 他 人 
使 用 ， 那 么 惑 会 出 现 资 源 不 断 在 两 个 线程 中 跳动 ， 而 没有 一 个 线程 可 
以 同时 拿 到 所 有 资源 而 正常 执行 。 这 种 情况 束 是 活 锁 。 


1.3 ”并 发 级 别 


由 于 临界 区 的 存在 ， 多 线程 之 间 的 并 发 必须 受到 控制 。 根 据 控制 
并 发 的 策略 ， 我 们 可 以 把 并 发 的 级 别 进行 分 类 ， 大 致 上 可 以 分 为 阻 
E ` TYR ` AE > AD o ERILE o 


1.3.1 PAS (Blocking) 


一 个 线程 是 阻塞 的 ， 那 么 在 其 他 线程 释放 资源 之 前 ， 当 前 线程 无 
法 继续 执行 。 当 我 们 使 用 synchronized 关 键 字 ， 或 者 重 入 锁 时 (我 们 将 
在 第 2、3 章 介绍 这 两 种 技术 ) ， 我 们 得 到 的 就 是 阻塞 的 线程 。 


无 论 是 synchronized 或 者 重 入 锁 ， 都 会 试图 在 执行 后 续 代 码 前 ， 得 
到 临界 区 的 锁 ， 如 果 得 不 到 ， 线 程式 会 被 挂 起 等 每 ， 直 到 占有 了 所 需 
资源 为 止 。 


1.3.2 FR (Starvation-Free) 


如 条 线程 之 间 征 有 优先 级 的 ， 那 么 线程 调度 的 时 候 总 是 会 倾 网 于 
满足 高 优先 级 的 线程 。 也 区 ® 说 是 ， 对 于 同一 个 资源 的 分 配 ， 古 不 公平 
的 ! 如 图 1.7 所 示 ， 显 示 了 非 公平 与 公平 两 种 情况 (五 角 星 表示 高 优先 
级 线程 ) 。 对 于 非 公 平 的 锁 来 说 ， 系 统 允 许 高 优先 级 的 线程 插队 。 这 
样 有 可 能 导致 低 优 移 级 线程 产生 饥 饿 。 但 如 果 锁 是 公平 的 ， 满 足 移 来 


后 到 ， 那 么 志 场 吏 不 会 产生 ， 不 管 新 来 的 线程 优 移 级 多 高 ， 要 想 获得 
痪 源 ， 吏 必须 乖乖 排队 。 那 么 所 有 的 线程 都 有 机 会 执行 。 
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图 1.7 “公平 与 非 公平 锁 


1.3.3 “无 障碍 (Obstruction-Free) 


无 障碍 是 一 种 最 弱 的 非 阻塞 调度 。 两 个 线程 如 果 是 无 障碍 的 执 
行 ， 那 么 他 们 不 会 因为 临界 区 的 问题 导致 一 方 被 挂 起 。 换 言 之 ， 大 家 
都 可 以 大 摇 大 摊 地 进入 临界 区 了 。 那 么 如 采 大 家 一 起 修改 共 至 数据 ， 
把 数据 改 坏 了 可 怎么 办 呢 ? 对 于 无 障碍 的 线程 来 说 ， 一 旦 检测 到 这 种 
情况 ， 它 束 会 立即 对 上 自己 所 做 的 修改 进行 回 深 ， 确 保 数 据 安全 。 但 如 
果 没 有 数据 苋 争 发 生 ， 那 么 线程 整 可 以 顺利 完成 目 己 的 工作 ， 走 出 临 
FTX. o 


如 果 说 阻塞 的 控制 方式 是 悲观 策略 。 也 就 是 说 ， 系 统 认为 两 个 线 
程 之 间 很 有 可 能 发 生 不 幸 的 冲突 ， 因 此 ， 以 保护 共享 数据 为 第 一 优先 
级 。 相 对 来 说 ， 非 阻塞 的 调度 束 是 一 种 乐观 的 策略 。 它 认为 多 个 线程 


之 间 很 有 可 能 不 会 发 生 冲 突 ， 或 者 说 这 种 概率 不 大 。 因 此 大 家 都 应 该 
无 障碍 的 执行 ， 但 是 一 旦 检测 到 冲突 ， 束 应 该 进行 回 深 。 


从 这 个 策略 中 也 可 以 看 到 ， 无 障碍 的 多 线程 程序 并 不 一 定 能 顺畅 
的 运行 。 因 为 当 临 界 区 中 存在 闫 重 的 冲突 时 ， 所 有 的 线程 可 能 都 会 不 
断 地 回 深 自己 的 操作 ， 而 没有 一 个 线程 可 以 走出 临界 区 。 这 种 情况 会 
影响 系统 的 正常 执行 。 所 以 ， 我 们 可 能 会 非常 布 望 在 这 一 堆 线程 中 ， 
至 少 可 以 有 一 个 线程 能 够 在 有 限 的 时 间 内 完成 目 己 的 操作 ， 而 退出 临 
界 区 。 至 少 这 样 可 以 保证 系统 不 会 在 临界 区 中 进行 无 限 的 等 待 。 


一 种 可 行 的 无 障碍 实现 可 以 依赖 一 个 “一 致 性 标记 ”来 实现 。 线 程 
在 操作 之 前 ， 先 读 取 并 保存 这 个 标记 ， 在 操作 完成 后 ， 再 次 读 取 ， 检 
查 这 个 标记 是 否 被 更 改过 ， 如 采 两 者 是 一 致 的 ， 则 说 明 资 产 访 问 没 有 
冲突 。 如 有 果 不 一 致 ， 则 说 明 资 源 可 能 在 操作 过 程 中 与 其 他 写 线程 剖 
突 ， 需 要 重 试 操作 。 而 任何 对 资源 有 修改 操作 的 线程 ， 在 修改 数据 
前 ， 都 需要 更 狐 这 个 一 致 性 标记 ， 表 示 数 据 不 再 安全 。 


1.3.4 FB (Lock-Free) 


无 锁 的 并 行 都 古 无 障碍 的 。 在 无 锁 的 情况 下 ， 所 有 的 线程 都 能 等 
试 对 临界 区 进行 访问 ， 但 不 同 的 是 ， 无 锁 的 并 发 保证 必然 有 一 个 线程 
能 够 在 有 限 步 内 完成 操作 离开 临界 区 。 


在 无 锁 的 调用 中 ， 一 个 典型 的 特点 和 是 可 能 会 包含 一 个 无 穷 循环 。 
在 这 个 循环 中 ， 线 程 会 不 断 答 试 修改 共享 变量 。 如 采 没 有 冲突 ， 修 改 
成 功 ， 那 么 程序 退出 ， 否 则 继续 尝试 修改 。 但 无 论 如 何 ， 无 锁 的 并 行 
总 能 保证 有 一 个 线程 是 可 以 胜出 的 ， 不 至 于 全 军 有 覆没 。 至 于 临界 区 中 


竞争 失败 的 线程 ， 它 们 则 必须 不 断 重 试 ， 直 到 目 己 获胜 。 如 有 果 运 气 很 
NE, Fe RMA BR, MA HWA ORR, BAER ELEN 
前 。 


下 面 台 是 一 段 无 锁 的 示意 代码 ， 如 采 修 改 不 成 功 ， 那 么 循环 永远 


while (!atomicVar.compareAndSet(localVar, localVar+i)) { 


localVar = atomicVar.get(); 


有 关 无 锁 ， 我 们 将 安排 在 “ 锁 的 优化 与 注意 事项 一 章 中 详细 介 


绍 。 


1.3.5 FSR (Wait-Free) 


无 锁 只 要 求 有 一 个 线程 可 以 在 有 限 步 内 完成 操作 ， 而 无 等 竺 则 在 
无 锁 的 基础 上 更 进一步 进行 扩展 。 它 和 要求 所 有 的 线程 都 必须 在 有 限 步 
ALTER, ŽANRS EYL Ale o WIR PR IA TPG EPR, xB ATLA 
进一步 分 解 为 有 办 无 等 每 和 线程 数 无 关 的 无 等 待 几 种 ， 它 们 之 间 的 区 
别 只 是 对 循环 次 数 的 限制 不 同 。 


一 种 典型 的 无 等 待 结构 就 是 RCU (Read-Copy-Update) 。 它 的 基 
本 思想 是 ， 对 数据 的 读 可 以 不 加 控制 。 因 此 ， 所 有 的 读 线程 都 是 无 等 
待 的 ， 它 们 既 不 会 被 锁定 等 待 也 不 会 引起 任何 神 突 。 但 在 写 数据 的 时 
候 ， 先 取得 原始 数据 的 副本 ， 接 着 只 修改 副本 数据 (这 就 是 为 什么 读 
可 以 不 加 控制 ) ， 修 改 完成 后 ， 在 合适 的 时 机 回 写 数据 。 


14 有 关 并 行 的 两 个 重要 定律 


有 天 为 什么 要 使 用 并 行程 序 的 问题 在 之 前 已 经 进行 了 简单 的 探 
讨 。 总 的 来 说 ， 最 重要 的 应 该 是 出 于 两 个 目的 。 第 一 ， 为 了 获得 更 好 
的 性 能 ， 第 二 ， 由 于 业务 模型 的 需要 ， 确 实 需要 多 个 执行 实体 。 在 这 
里 ,我 将 更 加 关注 于 第 一 种 情况 ， 也 束 是 有 关 性 能 的 问题 。 将 串 行程 
序 改造 为 并 发 ， 一 般 来 说 可 以 提供 程序 的 整体 性 能 ， 但 是 完 竟 能 提高 
多 少 ， 甚 至 说 究竟 是 否 真 的 可 以 提高 ， 还 是 一 个 需要 全 究 的 问题 。 目 
前 ， 主 要 有 两 个 定律 对 这 个 问题 进行 解答 ， 一 个 是 Amdahl 定 律 ， 另 外 
一 个 是 Gustafson 定 律 。 


1.4.1 Amdahl 定 律 


Amdahl 定 律 是 计算 机 科学 中 非常 重要 的 定律 。 写 定义 了 串 行 系统 
并 行 化 后 的 加 速 比 的 计算 公式 和 理论 上 限 。 


WERKEN: 加 速 比 = 优化 前 系统 耗 时 / 优化 后 系统 耗 时 


即 ， 所 谓 加 速 比 ， 融 是 优化 前 的 耗 时 与 优化 后 耗 时 的 比值 。 加 速 
比 越 高 ， 表 明 优 化 效果 越 明 显 。 图 1.8 显 示 了 Amdahl 公 式 的 推导 过 程 ， 
其 中 n 表 示 处 理 峰 个 数 ，T 表 示 时 间 ，TI1 表 示 优 化 前 耗 时 〈 也 就 是 只 有 
1 个 处 理 器 时 的 耗 时 ) ，Tn 表 示 使 用 n 个 处 理 器 优化 后 的 耗 时 。 了 下 是 程 
序 中 只 能 串 行 执 行 的 比例 。 


Ta = 
| Pe N 
| Yi | 并 行 比分 | R 
Y \ 
AZ TEA i 
| 7I — KRAAI jtag 
P2k = Ta kha fiig 
Ti CF t= (1-F)) 
| 
he eee 
E 
P+a CrP) 


dq 


图 1.8 Amdahl 公式 的 推 


根据 这 个 公式 ， 如 采 CPU 处 理 凑 数量 趋 于 无 穷 ， 那 么 加 速 比 与 系 
统 的 串 行 化 率 成 反比 ， 如 果 系 统 中 必须 有 50% 的 代码 串 行 执行 ， 那 么 
系统 的 最 大 加 速 比 为 2。 

假设 有 一 程序 分 为 以 下 步骤 执行 ， 每 个 执行 步骤 花费 100 个 时 间 单 
位 。 其 中 ， 只 有 步骤 2 和 步 又 5 可 以 进行 并 行 ， 步 又 1、3、4 必 须 囊 行 ， 
如 图 1.9 所 示 。 在 全 捉 行 的 情况 下 ， 系 统合 计 耗 时 500 个 时 间 单 位 。 


图 1.9 RT LETTE 


各 将 步 又 2 和 步骤 5 并 行 化 ， 假 设 在 双核 处 理 上 ， 则 有 如 图 1.10 所 
示 的 处 理 流 程 。 在 这 种 情况 下 ， 步 骤 2 和 步骤 5 的 耗 时 将 为 50 个 时 间 单 
位 。 故 系统 整体 耗 时 为 400 个 时 间 单 位 。 根 据 加 速 比 的 定义 有 : 


加 速 比 = 优化 前 系统 耗 时 /优化 后 系统 耗 时 = 500 / 400 = 1.25 


四 此 6) | |o0 | 


p $ 6 4 
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图 1.10 ”双核 处 理 上 的 并 行 化 


或 者 根据 前 文中 给 出 的 加 速 比 公式 。 由 于 5 个 步骤 中 ，3 个 步 又 必 


须 串 行 ， 因 此 其 串 行 化 比重 为 45=0.6， 即 F=0.6， 且 双核 处 理 器 的 处 理 
器 个 数 N 为 2。 代 入 公式 得 : 


加 速 比 =1/(0.6+(1-0.6)/2)=1.25 


在 极端 情况 下 ， 假 设 并 行 处 理 絮 个 数 为 无 穷 大 ， 则 有 如 图 1.11 所 
示 的 处 理 过 程 。 步 骤 2 和 步骤 5 的 处 理 时 间 趋 于 0。 即 使 这 样 ， 系 统 整体 
耗 时 依然 大 于 300 个 时 间 单 位 。 即 加 速 比 的 极限 为 500/300=1.67 ° 


图 1.11 极端 情况 下 的 并 行 化 


使 用 加 速 比 计算 公式 ，N 趋 于 无 穷 大 ， 有 加 速 比 =IE， 且 F=0.6， 
故 有 加 速 比 =1.67。 


由 此 可 见 ， 为 了 提高 系统 的 速度 ， 仅 增加 CPU 处 理 融 的 数量 并 不 
一 定 能 起 到 有 效 的 作用 。 需 要 从 根本 上 修改 程序 的 串 行 行 为 ， 拓 高 系 
统 内 可 并 行 化 的 模块 比重 ， 在 此 基础 上 ， 合 理 增加 并 行 处 理 器 数量 ， 
才能 以 最 小 的 投入 ， 得 到 最 大 的 加 速 比 。 


注意 : 根据 Amdahl 定 律 ， 使 用 多 核 CPU 对 系统 进行 优化 ， 优 化 的 
效果 取决 于 CPU 的 数量 以 及 系统 中 的 串 行 化 程序 的 比重 。CPU 数 
量 越 多 ， 串 行 化 比重 越 低 ， 则 优化 效果 越 好 。 仅 所 高 CPU 数量 而 
不 降低 程序 的 串 行 化 比重 ， 也 无 法 提高 系统 性 能 。 


1.4.2 Gustafson fë 


Gustafson E E E WA HH bE a PA > BÍT EE AA OR FE Z Ta AY 
关系 ， 如 图 1.12 所 示 ， 但 是 Gustafson 定 律 和 Amdahl 定 律 的 角度 不 同 。 
同样 ， 加 速 比 都 定义 为 优化 前 的 系统 耗 时 除 以 优化 后 的 系统 耗 时 。 
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图 1.12 ”Gustafson 定 律 的 推导 


可 以 看 到 ， 由 于 切入 角度 的 不 同 ，Gustafson 定 律 的 公式 和 Amdahl 
定律 的 公式 截然 不 同 。 从 Gustafson 定 律 中 ， 我 们 可 以 更 容易 地 发 现 ， 
如 采 串 行 化 比例 很 小 ， 并 行 化 比例 很 大 ， 那 么 加 速 比 就 是 处 理 锅 的 个 
数 。 只 要 你 不 断 地 累加 处 理 器 ， 束 能 获得 更 快 的 速度 。 


1.4.3 Amdahl Œ # Al Gustafson © Œ 
是 否 相互 矛盾 


由 于 Amdahl 定 律 和 Gustafson 定 律 的 结论 不 同 ， 这 是 不 是 说 明 这 两 
个 理论 之 加 有 一 个 是 错误 的 呢 ? 其 实 不 然 ， 两 者 的 差异 其 实 是 因为 这 


两 个 定律 对 同一 个 客观 事实 从 不 同 角 度 去 审视 后 的 结果 ， 它 们 的 偏重 
点 有 所 不 同 。 

举 一 个 生活 的 例子 ， 一 辆 汽车 行驶 在 相 窜 60 公 里 的 城市 。 你 花 了 
一 个 小 时 ,行驶 了 30 公 里 。 无 论 返 下 来 开 多 快 ， 你 都 不 可 能 达到 90 公 
里 /小 时 的 时 速 。 图 1.13 很 好 地 说 明了 原因 。 
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图 1.13 Amdahl 定 律 的 偏重 点 


求解 图 1.13 中 的 方程 ， 你 会 发 现 如 果 你 想 达到 90 公 里 的 时 速 ， 那 
么 你 从 AB 中 点 到 达 B 点 的 时 间 会 是 一 个 负数 ， 这 显然 不 是 一 个 合理 的 
结论 。 实 际 上 ， 如 有 果 前 半 程 30km 你 使 用 了 一 人 小时， 那么 即使 你 从 中 点 
到 B 点 使 用 光速 ， 也 只 能 把 整体 的 平均 时 速 维持 在 60km/hour 。 


也 就 是 说 Amdahl 强 调 ， 当 串 行 比例 一 定时 ， 加 速 比 是 有 上 限 的 ， 
不 管 你 堆 苔 多少 个 CPU 参 与 计算 ， 都 不 能 突破 这 个 上 限 ! 


而 Gustafson 定 律 的 出 发 点 与 之 不 同 ， 对 Gustafson 定 律 来 说 ， 不 管 
你 从 A 点 出 发 的 速度 有 多 慢 ， 只 要 给 你 足够 的 时 间 和 距离 ， 只 要 你 后 
期 的 速度 比 期 望 值 快 那么 一 点 点 ， 你 总 是 可 以 把 平均 速度 调整 到 非常 
接近 那个 期 望 值 的 。 比 如 ， 你 想 要 达到 均 速 90km/hour， 即 使 在 前 
30km 你 的 时 速 只 有 30km/hour， 你 只 要 在 很 后 面 的 速度 达到 


91km/hour， 给 你 足够 的 时 间 和 距离 ， 你 总 有 一 天 可 以 把 均 速 提高 到 
90km/hour ° 


因此 ，Gustafson 定 律 关心 的 是 : 如 果 可 被 并 行 化 的 代码 所 占 比 重 
足够 多 ， 那 么 加 速 比 就 能 随 着 CPU 的 数量 线性 增长 。 


所 以 ， 这 两 个 定律 并 不 矛盾 。 从 极端 角度 来 说 ， 如 采 系 统 中 没有 
可 被 串 行 化 的 代码 (BUF=1) ， 那 么 对 于 这 两 个 定律 ， 其 加 速 比 都 是 
1。 反 之 ， 如 果 系 统 中 可 串 行 化 代码 比重 达到 100%， 那 么 这 两 个 定律 
得 到 加 速 比 都 是 n (处 理 器 个 数 ) 。 


1.5 回 到 Java:，JMM 


前 面 我 已 经 介绍 了 有 关 并 行程 序 的 一 些 关 键 概念 和 定律 。 这 些 概 
念 可 以 说 是 与 语言 无 关 的 。 无 论 你 使 用 Java 或 者 C， 或 者 其 他 任何 一 门 
语言 编写 并 发 程序 ， 都 有 可 能 会 涉及 这 些 问题 。 但 本 书 依然 是 一 本 面 
器 Java 程 序 员 的 书籍 。 因 此 ， 在 本 章 最 后 ， 我 们 还 是 希望 可 以 探讨 一 
下 有 关 Java 的 内 存 模 型 (JMM) ° 


由 于 并 发 程序 要 比 串 行程 序 复 杂 很 多 ， 其 中 一 个 重要 原因 十 并 发 
程序 下 数据 访问 的 一 致 性 和 安全 性 将 会 受到 严重 挑战 。 如 何 保证 一 个 
线程 可 以 看 到 正确 的 数据 呢 ? 这 个 问题 看 起 来 很 白痴 。 对 于 串 行程 序 
来 说 ， 根 本 束 是 小 来 一 碟 ， 如 采 你 读 取 一 个 变量 ， 这 个 变量 的 值 是 1， 
那么 你 读 到 的 一 定 是 1， 束 这 么 简单 的 问题 在 并 行程 序 中 居然 变 得 复杂 
起 来 。 事 实 上 ， 如 果 不 加 控制 地 任 由 线程 胡乱 并 行 ， 即 使 原本 是 1 的 数 
值 ， 你 也 有 可 能 读 到 2。 因 此 ， 我 们 需要 在 深入 了 解 并 行 机 制 的 前 提 
下 ， 再 定义 一 种 规则 ， 保 证 多 个 线程 间 可 以 有 效 地 、 正 确 地 协同 工 
作 。 而 JMM 也 束 是 为 此 而 生 的 。 


JMM 的 关键 技术 点 都 是 围绕 着 多 线程 的 原子 性 、 可 见 性 和 有 序 性 
来 建立 的 。 因 此 ， 我 们 首先 必须 了 解 这 些 概念 。 


1.5.1 原子 性 (Atomicity) 


原子 性 是 指 一 个 操作 十 不 可 中 断 的 。 即 使 征 在 多 个 线程 一 起 执行 
的 时 候 ， 一 个 操作 一 旦 开始 ， 束 不 会 被 其 他 线程 干扰 。 


比如 ， 对 于 一 个 静态 全 局 变量 int i， 两 个 线程 同时 对 它 赋 值 ， 线 
程 A 给 他 赋值 1， 线 程 B 给 它 赋 值 为 -1。 那 么 不 管 这 2 个 线程 以 何 种 方 
式 、 何 种 步调 工作 ，i 的 值 要 么 是 1， 要 么 是 -1。 线 程 A 和 线程 B 之 间 坪 
没有 干扰 的 。 这 吏 是 原子 性 的 一 个 特点 ， 不 可 被 中 断 。 


但 如 果 我 们 不 使 用 int 型 而 使 用 long 型 的 话 ， 可 能 束 没 有 那么 地 运 
了 。 对 于 32 位 系统 来 说 ，long 型 数据 的 读 写 不 是 原子 性 的 (因为 long 
有 64 位 ) 。 也 就 是 说 ， 如 果 两 个 线程 同时 对 long 进 行 写 入 的 话 (或 者 
读 取 ) ， 对 线程 之 间 的 结果 是 有 干扰 的 。 


大 家 可 以 仔细 观察 一 下 下 面 的 代码 : 


public class MultiThreadLong { 
public static long t=0; 
public static class ChangeT implements Runnable{ 
private long to; 
public ChangeT(long to){ 
this.to=to; 
i 
@Override 
public void run() { 
while(true) { 
MultiThreadLong.t=to; 
Thread. yield(); 
i 


} 


public static class ReadT implements Runnable{ 


@Override 
public void run() { 
while(true) { 
long tmp=MultiThreadLong.t; 
if(tmp!=111L && tmp!=-999L && tmp!=333L && 
tmp !=-444L) 
System.out.printlin(tmp); 
Thread. yield(); 
} 


public static void main(String[] args) { 
new Thread(new ChangeT(111L)).start(); 
new Thread(new ChangeT(-999L)).start(); 
new Thread(new ChangeT(333L)).start(); 
new Thread(new ChangeT(-444L)).start(); 


new Thread(new ReadT()).start(); 


上 述 代 码 有 4 个 线程 对 long 型 数据 {t 进 行 赋值 ， 分 别 对 {t 赋 值 为 
111、-999、333、444。 然 后 ， 有 一 个 读 取 线 程 ， 读 取 这 个 {t 的 值 。 一 
般 来 说 ，t 的 值 总 是 这 4 个 数值 中 的 一 个 。 这 当然 也 是 我 们 的 期 望 了 。 
但 很 不 幸 ， 在 32 位 的 Java 虚 拟 机 中 ， 未 必 总 是 这 样 。 


如 果 读 取 线 程 ReadT 总 是 读 到 合理 的 数据 ， 那 么 这 个 程序 应 该 没 
有 任何 输出 。 但 是 ， 实 际 上 ， 这 个 程序 一 旦 运行 ， 束 会 大 量 输出 以 下 
afd: (再 次 强调 ， 使 用 32 位 虚拟 机 ) 


-4294966963 
4294966852 
-4294966963 


这 里 截取 了 部 分 输出 。 我 们 可 以 看 到 ， 读 取 线 程 居 然 读 到 了 两 个 
似乎 根本 不 可 能 存在 的 数值 。 这 不 是 幻觉 ， 在 这 里 ， 你 看 到 的 确实 是 
事实 ， 其 中 的 原因 也 惑 是 因为 32 位 系统 中 long 型 数据 的 读 和 写 都 不 是 
原子 性 的 ， 多 线程 之 间 相 互 干 扰 了 |! 


如 有 果 我 给 出 这 几 个 数值 的 2 进 制 表示 ， 大 家 束 会 有 更 清晰 的 认识 
T: 


+111=0000000000000000000000000000000000000000000000000000000001 
101111 
-999=1111111111111111111111111111111111111111111111111111110000 
011001 
+333=0000000000000000000000000000000000000000000000000000000101 
001101 
-444=1111111111111111111111111111111111111111111111111111111001 
000100 
+4294966852=000000000000000000000000000000001111111111111111111 
1111001000100 


-4294967185=111111111111111111111111111111110000000000000000000 
0000001101111 


上 面 显 示 了 这 几 个 相关 数字 的 补 码 形式 ， 也 就 是 在 计算 机 内 的 真 
实 存 储 内 容 。 不 难 发 现 ， 这 个 奇怪 的 4294966852， 其 实 是 111 或 者 333 
的 前 32 位 ， 与 -444 的 后 32 位 夹杂 后 的 数字 。 而 -4294967185 只 是 -999 或 
者 -444 的 前 32 位 与 111 夹 洒 后 的 数字 。 换 句 话 说， 由 于 并 行 的 关系 ， 数 
字 被 写 乱 了 ， 或 者 读 的 时 候 ， 读 串 位 了 。 


通过 这 个 例子 ， 我 想 大 家 都 原子 性 应 该 有 了 基本 的 认识 。 
1.5.2 可见 性 (Visibility) 


可 见 性 是 指 当 一 个 线程 修改 了 某 一 个 共 至 变量 的 值 ， 其 他 线程 是 
否 能 够 立即 知道 这 个 修改 。 显 然 ， 对 于 串 行 程序 来 说 ， 可 见 性 问题 是 
不 存在 的 。 因 为 你 在 任何 一 个 操作 步 又 中 修改 了 茶 个 变量 ， 那 么 在 后 
续 的 步骤 中 ， 读 取 这 个 变量 的 值 ， 一 定 是 修改 后 的 新 值 。 


但 是 这 个 问题 在 并 行程 序 中 就 不 见得 了 。 如 果 一 个 线程 修改 了 某 
一 个 全 局 变量 ， 那 么 其 他 线程 未 必 可 以 马上 知道 这 个 改动 。 图 1.14 展 
示 了 发 生 可 见 性 问题 的 一 种 可 能 。 如 果 在 CPU1 和 CPU2 上 各 运行 了 一 
个 线程 ， 它 们 共享 变量 {， 由 于 编译 器 优化 或 者 硬件 优化 的 缘故 ， 在 
CPU1 上 的 线程 将 变量 {t 进 行 了 优化 ， 将 其 缓存 在 cache 中 或 者 寄存 器 
里 。 这 种 情况 下 ， 如 果 在 CPU2 上 的 某 个 线程 修改 了 变量 t 的 实际 值 ， 
那么 CPU1 上 的 线程 可 能 并 无 法 意识 到 这 个 改动 ， 依 然 会 读 取 cache 中 
或 者 寄存 器 里 的 数据 。 因 此 ， 就 产生 了 可 见 性 问题 。 外 在 表现 为 : 变 


量 t 的 值 被 修改 ， 但 是 CPU1 上 的 线程 依然 会 读 到 一 个 旧 值 。 可 见 性 问 
题 也 是 并 行程 序 开发 中 需要 重点 关注 的 问题 之 一 。 


AB t 
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， |È 
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图 1.14 可见 性 问题 


可 见 性 问题 是 一 个 绿 合 性 问题 。 除 了 上 述 提 到 的 缓存 优化 或 者 全 
件 优 化 (有 些 内 存 读 写 可 能 不 会 立即 触发 ， 而 会 先进 入 一 个 硬件 队列 
等 待 ， 会 导致 可 见 性 问题 外 ， 指 令 重 排 (这 个 问题 将 在 下 一 方 中 更 详 
细 讨 论 ) 以 及 编辑 器 的 优化 ， 都 有 可 能 导致 一 个 线程 的 修改 不 会 立即 
极其 他 线程 察觉 。 


下 面 来 看 一 个 简单 的 例子 : 


Thread 1 Thread 2 
2A 00 NB, 


2: B=1; 4: A= 2; 


上 述 两 个 线程 ， 并 行 执 行 ， 分 别 有 1、2、3、4 四 条 指令 。 其 中 指 
令 1、2 属 于 线程 1， 而 指令 3、4 属 于 线程 2。 


从 指令 的 执行 顺序 上 看 ，r2==2 并 且 r1==1 似 乎 是 不 可 能 出 现 的 。 
但 实际 上 ， 我 们 并 没有 办 法 从 理论 上 保证 这 种 情况 不 出 现 。 因 为 编译 
堪 可 能 将 指令 重 排 成 : 


Thread 1 Thread 2 
Bread alee 


r2 =A; A = 2; 


在 这 种 执行 顺序 中 ， 就 有 可 能 出 现 刚才 看 似 不 可 能 出 现 的 r2==2 并 
且 r1==1 的 情况 了 。 


这 个 例子 哆 说 明 ， 在 一 个 线程 中 去 观察 另外 一 个 线程 的 变量 ， 它 
们 的 值 是 否 能 观测 到 、 何 时 能 观测 到 是 没有 保证 的 。 


再 来 看 一 个 稍微 复杂 一 些 的 例子 : 


Thread 1 Thread 2 
rl = p; r6 = p; 

F2 = six LOX E=; 
r3 = q; 

r4 = r3.x; 


RS = 1 


这 里 假设 在 初始 时 ，p == q 并 且 p.x == 0。 对 于 大 部 分 编译 器 来 
说 ， 可 能 会 对 线程 1 进行 加 前 蔡 换 的 优化 ， 也 束 是 r5=r1.x 这 条 指令 会 被 
直接 奉 换 成 r5=r2。 因 为 它们 都 读 取 了 rl.x， 又 发 生 在 同一 个 线程 中 ， 
因此 ， 编 译 器 很 可 能 认为 第 2 次 读 取 是 完全 没有 必要 的 。 因 此 ， 上 壕 指 


Thread 1 Thread 2 


ri = ð; r6 = p; 

r2 = r1.x; r6.xX = 3; 
r3 = q; 

r4 = r3.x; 

r5 = r2; 


现在 思考 这 么 一 种 场景 。 假 设 线 程 2 中 的 r6.x=3 发 生 在 r2 = r1.x 和 r4 
= I3.x 之 间 ， 而 编译 希 又 打算 重用 r2 来 表示 r5。 那 么 瑟 有 可 能 会 出 现 非 
常 奇怪 的 现象 。 你 看 到 的 r2 是 0，r4 是 3， 但 是 5 还 是 0。 因此 ， 如 果 从 
线程 1 代码 的 直观 感觉 上 看 就 是 p.x 的 值 从 0 变 成 了 3 (因为 4 是 3) ， 
接着 又 变 成 了 0 〈 这 是 不 是 算 一 个 非常 怪异 的 问题 呢 ? ) 


1.5.3 tE (Ordering) 


有 序 性 问题 可 能 是 三 个 问题 中 最 难 理解 的 了 。 对 于 一 个 线程 的 执 
行 代码 而 言 ， 我 们 总 是 习惯 地 认为 代码 的 执行 是 从 先 往 后 ， 依 次 执行 
的 。 这 么 理解 也 不 能 说 完全 错误 ， 因 为 驶 一 个 线程 内 而 言 ， 确 实 会 表 
现成 这 样 。 但 是 ， 在 并 发 时 ， 程 序 的 执行 可 能 束 会 出 现 乱 序 。 给 人 直 
WAVES ot Bie: 写 在 前 面 的 代码 ， 会 在 后 面 执行 。 听 起 来 有 些 不 可 思 
W, Æ? 有 序 性 问题 的 原因 是 因为 程序 在 执行 时 ， 可 能 会 进行 指令 
重 排 ， 重 排 后 的 指令 与 原 指 令 的 顺序 未 必 一 致 。 下 面 来 看 一 个 简单 的 
PIF: 


01 class OrderExample { 
02 int a = 0; 


03 boolean flag = false; 


04 public void writer() { 


05 a= 1; 
06 flag = true; 
07 } 


08 public void reader() { 


09 if (flag) { 

10 int i= a +1; 
LAs es: 

12 } 

13:3} 

14 } 


假设 线程 A 首 先 执行 writer0 方 法 ， 接 着 线程 B 执 行 reader0 方 法 ， 
如 果 发 生 指 令 重 排 ， 那 么 线程 B 在 代码 第 10 行 时 ， 不 一 定 能 看 到 a 已 经 
被 赋值 为 了。 如 图 1.15 所 示 ， 显 示 了 两 个 线程 的 调用 关系 。 
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图 1.15 ”指令 重 排 引起 线程 间 语义 不 一 致 


这 确实 是 一 个 看 起 来 很 奇怪 的 问题 ,但 是 它 确实 可 能 存在 。 注 
Bm: 我 这 里 说 的 是 可 能 存在 。 因 为 如 果 指 令 没有 重 排 ， 这 个 问题 就 不 


存在 了 ， 但 是 指令 是 否 发 生 重 排 、 如 何 重 排 ， 孜 但 是 我 们 无 法 预测 
的 。 因 此 ， 对 于 这 类 问题 ,我 认为 比较 天 齐 的 描述 是 ， 线 程 A 的 指令 
执行 顺序 在 线程 B 看 来 是 没有 保证 的 。 如 果 运 气 好 的 话 ， 线 程 B 也 许 真 
的 可 以 看 到 和 线程 A 一 样 的 执行 顺序 。 


不 过 这 里 还 需要 强调 一 点 ， 对 于 一 个 线程 来 说 ， 它 看 到 的 指令 执 
行 顺 序 一 定 是 一 致 的 〈 否 则 的 话 我 们 的 应 用 根本 无 法 正常 工作 ， 不 是 
吗 ? ) 。 也 就 是 说 指令 重 排 症 有 一 个 基本 前 提 的 ， 就 是 保证 串 行 语义 
的 一 致 性 。 指 令 重 排 不 会 使 串 行 的 语义 逻辑 发 生 问 题 。 因 此 ， 在 串 行 
代码 中 ， 大 可 不 必 担 心 。 


TER: 指令 重 排 可 以 保证 串 行 语 义 一 致 ， 但 是 没有 义务 保证 多 线 
程 间 的 语义 也 一 致 。 


那么 ， 好 柯 的 你 可 能 马上 束 会 在 脑海 里 内 出 一 个 疑问 ， 为 什么 要 
指令 重 排 呢 ?让 他 一 步 一 步 执行 多 好 呀 ! 也 不 会 有 那么 多 奇 琵 的 问 


题 。 


之 所 以 那么 做 ， 完 全 是 因为 性 能 考虑 。 我 们 知道 ， 一 条 指令 的 执 
行 是 可 以 分 为 很 多 步 又 的 。 简 单 地 说 ， 可 以 分 为 以 下 几 步 : 


。 取 指 IF 

译 码 和 取 寄 存 器 操作 数 ID 
执行 或 者 有 效 地 址 计算 EX 
存储 器 访问 MEM 

。 与 回 WB 


我 们 的 汇编 指令 也 不 是 一 步 殉 可 以 执行 完毕 的 ， 在 CPU 中 实际 工 
作 时 ， 它 还 是 需要 分 为 多 个 步骤 依次 执行 的 。 当 然 ， 每 个 步 又 所 涉及 


的 硬件 也 可 能 不 同 。 比 如 ， 取 指 时 会 用 到 PC 寄存 器 和 存储 器 ， 译 人 码 时 
会 用 到 指令 寄存 右 组 ， 执 行 时 会 使 用 ALU， 写 回 时 需要 寄存 如 组 。 


JER: ALU 指 算术 逻辑 单元 。 它 是 CPU 的 执行 单元 ， 是 CPU 的 核 
心 组 成 部 分 ， 主 要 功能 是 进行 二 进 制 算术 运算 。 


由 于 每 一 个 步 又 都 可 能 使 用 不 同 的 硬件 完成 ， 因 此 ， 聪 明 的 工程 
师 们 殊 发 明了 流水 线 技术 来 执行 指令 ， 如 图 1.16 所 示 ， 显 示 了 流水 线 
的 工作 原理 。 


tg! D EX MEM WE 
AAI 
442 FIV < NEM WD 


图 1.16 ”指令 流水 线 


可 以 看 到 ， 当 第 2 条 指令 执行 时 ， 第 1 条 执行 其 实 并 未 执行 完 ， 确 
切 地 说 第 一 条 指令 还 没 开始 执行 ， 只 是 刚刚 完成 了 取 值 操作 而 已 。 这 
样 的 好 处 非常 明显 ， 假 如 这 里 每 一 个 步 又 都 需要 花费 1 坚 秒 ， 那 么 指令 
2 等 待 指 令 1 完全 执行 后 ， 再 执行 ， 则 需要 等 得 5 上台 秒 ， 而 使 用 流水 线 
后 ， 指 令 2 只 需要 等 每 1 感 秒 束 可 以 执行 了 。 如 此 大 的 性 能 提升 ， 当 然 
让 人 眼红 。 更 何况 ， 实 际 的 商业 CPU 的 流水 线 级 别 甚 至 可 以 达到 10 级 
以 上 ， 则 性 能 提升 就 更 加 明显 。 


有 了 流水 线 这 个 神器 ， 我 们 CPU 才 能 真正 高 效 的 执行 ， 但 是， 别 
瑟 了 一 点 ， 流 水 线 总 是 害怕 被 中 断 的。 流水 线 满 载 时 ， 人 性 能 确实 相当 
不 错 ， 但 征 一 旦 中 断 ， 所 有 的 硬件 设备 都 会 进入 一 个 停顿 期 ， 再 次 满 
载 又 需要 儿 个 周期 ， 因 此 ， 人 性 能 损失 会 比较 大 。 所 以 ， 我 们 必须 要 想 
办 法 尽量 不 让 流水 线 中 断 ! 


那么 答案 就 来 了 ， 之 所 以 需要 做 指令 重 排 ， 就 是 为 了 尽量 少 的 中 
断 流水 线 。 当 然 了 ， 指 令 重 排 只 是 减少 中 断 的 一 种 技术 ， 实 际 上 ， 在 
CPU 的 设计 中 ， 我 们 还 会 使 用 更 多 的 软 硬 件 技术 来 防止 中 断 ， 不 过 对 
它们 的 讨论 已 经 远 远 超出 本 书 范围 ， 有 兴趣 的 读者 可 以 查阅 相关 次 
料 。 


让 我 们 来 仔细 看 一 个 例子 。 图 1.17 展 示 了 A=B+C 这 个 操作 的 执行 
过 程 。 写 在 左边 的 指令 瓯 是 汇编 指令 。LW 表 示 load， 其 中 LW R1,B, 
表示 把 B 的 值 加 载 到 R1 寄 存 器 中 。ADD 指 令 就 是 加 法 ， 把 R1、R2 的 值 
相 加 ， 并 存放 到 R3 中 。SW 表 示 store， 存 储 ， 就 是 将 R3 寄 存 器 的 值 保 
存 到 变量 A 中 。 
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图 1.17 A=B+C 的 执行 过 程 


右边 就 是 流水 线 的 情况 。 注 意 ， 在 ADD 指 令 上 ， 有 一 个 大 叉 ， 表 
示 一 个 中 断 。 也 就 是 说 ADD 在 这 里 停顿 了 一 下 。 为 什么 ADD 会 在 这 里 
停顿 昵 ? 原因 很 镜 单 ，R2 中 的 数据 还 没有 准备 好 ! 所 以 ，ADD 操 作 必 
须 进 行 一 次 等 待 。 由 于 ADD 的 延迟 ， 导 致 其 后 面 所 有 的 指令 都 要 慢 一 
PAS 


理解 了 上 面 这 个 例子 ,我们 束 可 以 来 看 一 个 更 加 复杂 的 情 帝 : 


a=b+c 


d=e-f 
上 述 代 码 的 执行 应 该 会 是 这 样 ， 如 图 1.18 所 示 。 


LW bbb TF ID EX MEM WB 


LW Rec IF Ip EX MEM Wh 

ADD ba, Pb. Re rp LD x EX Mem WB 

SW Aka IF x DA Mam We 

LW ke, x IF ID EX MEM WB 

LW ff IF WD EX MeM wè 

sud Md Re RF zDD x EX Mem WB 

SW dhd IF x ID EX MM We 


R118 ” 重 排 前 指令 执行 过 程 


由 于 ADD 和 SUB 都 需要 等 待 上 一 条 指令 的 结果 ， 因 此 ， 在 这 里 插 
入 了 不 少 停顿 。 那 么 对 于 这 段 代 码 ， 是 否 有 可 能 消除 这 些 停 顿 呢 ? 显 
然 是 可 以 的 ， 如 图 1.19 所 示 ， 显 示 了 减少 这 些 停顿 的 方法 。 我 们 只 需 
要 将 LW Re, e 和 LW Rf, f 移 动 到 前 面 执行 即 可 。 思 想 很 简单 ， 移 加 载 e 
和 f 对 程序 是 没有 影响 的 。 既 然 在 ADD 的 时 候 一 定 要 停顿 一 下 ， 那 么 停 


顿 的 时 间 还 不 如 去 做 点 有 意义 的 事情 。 


LW pbb IF ID EX MEM WB 
LW Rec Tr Ww EX MM we 


ADV ba, Rb Re 六 ID x EX Mem WB 


rP 
SW ak, IF x ID EX M&M We 
LW Ree X If ID EX MM WB 
Ww YF 一 Tr 1D EX Mem wọ 
su BA Re RF r ID x EX MM WB 
sw dl if xX 2X A 


图 1.19 ”指令 重 排 ， 以 消除 停顿 


重 排 后 ， 最 终 的 结果 如 图 1.20 所 示 。 可 以 看 到 ， 所 有 的 停顿 都 已 
经 消除 ， 流 水 线 已 经 可 以 十 分 顺畅 地 执行 。 


LW pb,b TF ID EX MEM WB 
LW Roc Te ID EX MeN wọ 
LW ee IÈ ID EX MEM WB 
ADD ba, Rb. Re rp IO EX Mem WB 
Ww ff re Ip EX mem wọ 
LW 大 | 
SW Aka IF ID EX MH We 
J” ) 
| re I EX Miu Wi 
sud BA Re RF rp LD EX Mem WB 
SW ARA IF ID EX “M&M We 


1.20 ” 重 排 后 的 指令 


由 此 可 见 ， 指 令 重 排 对 于 提高 CPU 处 理性 能 是 十 分 必要 的 。 虽 然 
确实 带 来 了 乱 序 的 问题 ， 但 是 这 点 牺牲 是 完全 值得 的 。 


1.5.4 ”哪些 指令 不 能 重 排 ; Happen- 
Before 规 则 


在 前 文 已 经 介绍 了 指令 重 排 ,虽然 Java 虚 拟 机 和 执行 系统 会 对 指 
令 进行 一 定 的 重 排 ， 但 是 指令 重 排 是 有 原则 的 ， 并 非 所 有 的 指令 都 可 
以 随便 改变 执行 位 置 ， 以 下 罗列 了 一 些 基 本 原则 ， 这 些 原则 是 指令 重 
排 不 可 违背 的 。 


。 程序 顺序 原则 : 一 个 线程 内 保证 语义 的 串 行 性 


volatile 规 则 : volatile 变量 的 写 ， 先 发 生 于 读 ， 这 保证 了 volatile 
变量 的 可 见 性 

WAL: 解锁 (unlock) 必然 发 生 在 随后 的 加 锁 (lock) 前 
传递 性 ，A 先 于 B，B 先 于 C， 那 么 A 必然 先 于 C 

线程 的 start() 方 法 先 于 它 的 每 一 个 动作 

线程 的 所 有 操作 先 于 线程 的 终结 (Thread.join()) 

线程 的 中 断 (interrupt()) 先 于 被 中 断 线程 的 代码 

对 象 的 构造 函数 执行 、 结 束 先 于 finalize() 方 法 


以 程序 顺序 原则 为 例 ， 重 排 后 的 指令 绝对 不 能 改变 原 有 的 串 行 语 
ML 比如 : 


a=1; 


b=a+1; 


由 于 第 2 条 语句 依赖 第 一 条 的 执行 结 有 末 。 如 有 果 冒 然 区 换 两 条 语句 的 
执行 顺序 ， 那 么 程序 的 语义 融会 修改 。 因 此 这 种 情况 是 绝对 不 允许 发 
生 的 。 因 此 ， 这 也 是 指令 重 排 的 一 条 基本 原则 。 


此 外 ， 锁 规则 强调 ，unlock 操 作 必 然 发 生 在 后 续 的 对 同一 个 锁 的 
lock 之 前 。 也 就 是 讽 ， 如 条 对 一 个 锁 解 锁 后 ， 再 加 锁 ， 那 么 加 锁 的 动 
作 绝 对 不 能 重 排 到 解锁 动作 之 前 。 很 显然 ， 如 宁 这 么 做 ， 加 锁 行 为 是 
无 法 获得 这 把 锁 的 。 


其 他 几 条 原则 也 十 类 似 的 ， 这 些 原 则 都 是 为 了 保证 指令 重 排 不 会 
破坏 原 有 的 语义 结构 。 


1.6 参考 文献 


e Linus Torvalds: 访 挥 那 该 死 的 并 行 吧 ! 


o http://www.csdn.net/article/2015-01-08/2823487-linus-the-whole- 
parallel-computing-is-the-future-is-a-bunch 

o http://www.realworldtech.com/forum/? 
threadid=146066&curpostid=146227 


ARKEA 


o http://blog.sciencenet.cn/blog-1225851-840243.html 
。 有关 摩 尔 定 律 失效 


o http://blog.csdn.net/hsutter/article/details/1136281 


o http://www.zdnet.com/article/barrett-still-has-some-fight-in-him 


有 关 并 发 的 级 别 


o http://concurrencyfreaks.blogspot.hk/2013/05/lock-free-and-wait- 
free-definition-and.html 


o http://chuansong.me/n/862673 


Amdahl Œ 1€ 


o http://en.wikipedia.org/wiki/Amdahl's_law 


Gustafson í# 


o http://en.wikipedia.org/wiki/Gustafson's_law 
。 有 关 JMM 


o http://docs.oracle.com/javase/specs/jls/se7/html/jls-17 .html#jls- 
17.4 


。 AKEEF 
o 《计算 机 体系 结构 》. 浙江 大 学 出 版 社 . 石 教 英 等 编 


第 2 章 ”Java 并 行程 序 基 础 


我 们 已 经 探讨 为 什么 必须 面 对 并 行程 序 这 样 复杂 的 程序 设计 方 
法 ， 那 么 下 面 束 需 要 静 下 心 来 ， 认 真 研究 如 何 才能 构建 一 个 正确 、 健 
壮 并 且 高 效 的 并 行 系统 。 本 章 将 详细 介绍 有 关 Java 并 行程 序 的 设计 基 
础 ， 以 及 一 些 弟 见 的 问题 ,希望 对 读者 有 所 帮助 。 


2.1 有 关 线 程 你 必须 知道 的 事 


在 介绍 线程 前 ， 我 们 还 是 和 完了 解 一 下 线程 的 “ 母 茶 ”一 一 进程 。 如 
果 你 有 读 过 操作 系统 的 课程 ， 那 你 对 进程 一 定 不 会 卫生 。 在 这 种 专业 
级 的 书籍 中 ， 应 该 会 给 出 一 些 “ 官 方 "的 解释 ， 比 如 像 下 面 这 样 描述 : 


进程 (Process) 是 计算 机 中 的 程序 关于 某 数 据 集合 上 的 一 次 运行 
活动 ， 是 系统 进行 资源 分 配 和 调度 的 基本 单位 ， 是 操作 系统 结构 的 基 
础 。 在 早期 面 癌 进程 设计 的 计算 机 结构 中 ， 进 程 是 程序 的 基本 执行 实 
体 ， 在 当代 面向 线程 设计 的 计算 机 结构 中 ， 进 程 是 线程 的 容器 。 程 序 
是 指令 、 数 据 及 其 组 织 形式 的 摘 述 ， 进 程 是 程序 的 实体 。 


不 过 我 不 想 把 这 种 疡 谨 且 抽象 的 描述 介绍 给 大 家 。 用 一 句 简单 的 
话 来 说 ， 你 在 windows 中 ， 看 到 的 后 缀 为 .exe 的 文件 ， 都 是 一 个 程序 。 
不 过 程序 是 死 的 ， 静 态 的 。 当 你 双击 这 个 .exe 执 行 的 时 候 ， 这 个 .exe 文 
件 中 的 指令 束 会 被 加 载 ， 那 么 你 束 能 得 到 一 个 有 关 这 个 .exe 程 序 的 一 
个 进程 。 进 程 是 “ 活 ” 的 ， 或 者 说 是 正在 被 执行 的 。 图 2.1 使 用 任务 管理 
郁 ， 显 示 了 当前 系统 中 的 进程 。 


进程 数 : 115 CPU 使 用 率 : 6% 物理 内 存 : 44% 


图 2.1 系统 进程 信息 


进程 中 可 以 容纳 若干 个 线程 。 它 们 并 不 是 看 不 见 、 摸 不 着 的 ， 也 
可 以 使 用 工具 看 到 它们 ， 如 图 2.2 所 示 。 


On es 
Performance | Performance Graph | Disk and Network 
Threads | TCP/IP | Security | Environment | Strings 


es... Start Address 


606,464 MSVCRi00. dil!_endthreadex~0x80 
MSVCRi00. dii!_endthreadex+0x80 

483 MSVCR100. dli!_endthreadex-0x80 
MSVCR100. dil!_endthreadex+0x80 
MSVCR100. dll!_endthreadex~0x80 
MSVCR100. dil!_endthreadex+0x80 
MSVCR100. dll!_endthreadex+0x80 


MSVCR100. dil!_endthreadex+0x80 
MSVCR100. dl1!_endthreadex+0x80 
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Wait:WrUserRequest Base Priority: 

0:00:05.850 Dynamic Priority: 

0:00:14.991 I/O Priority: 
Context Switches: 287,235 Memory Priority: 
Cydes: 75, 167,745,569 Ideal Processor: 


图 2.2 ”进程 中 线程 的 信息 


那 线程 和 进程 之 间 冤 竟 生 一 种 什么 样 的 关系 呢 ? 简单 地 说 ， 进 程 
征 一 个 容 吉 。 比 如 一 间 漂 亮 的 小 别墅 。 别 时 里 有 电视 、 厨 房 、 书 房 、 
洗手 间 等 。 当 然 ， 还 有 一 家 三 口 住 在 里 面 。 当 妈妈 市 女儿 外 出 游玩 
时 ， 和 爸爸 一 人 在 家 。 这 时 和 爸爸 一 个 人 在 家 里 爱 上 哪里 去 哪里 、 爱 干 嘛 
干 嘛 ， 这 时 ， 和 爸爸 就 像 一 个 线程 “这 个 进程 中 只 有 一 个 活动 线程 ) ， 
小 别墅 束 像 一 个 进程 ， 家 里 的 电视 、 厨 房 、 书 房 环 像 这 个 进程 占有 的 
资源 。 当 到 三 个 人 住 在 一 起 时 《相当 于 三 个 线程 ) ， 有 时 候 可 能 就 会 
有 些小 冲突 ， 比 如 ， 当 女儿 占 着 电视 机 看 动画 片 时 ， 和 爸爸 殉 不 能 看 体 
育 频道 了 ， 这 残 是 线程 间 的 唤 源 竞争 。 当 然 ， 大 部 分 时 候 ， 线 程 之 间 
还 是 协作 关系 (如 采 我 们 创建 线程 是 用 来 打架 的 ， 那 创建 它 干 嘛 
We? ) 。 比 如 ， 妈 妈 在 厨房 为 欠 和 多 和 女儿 做 饭 ， 和 爸爸 在 书房 工作 赚钱 


养家 糊口 ， 女 儿 在 写作 业 ， 各 司 其 职 ， 那 么 这 个 家 就 是 其 乐 融融 了 ， 
相对 的 ， 这 个 进程 也 就 在 健康 地 执行 。 


用 稍微 专业 点 的 术语 说 ， 线 程 束 是 轻 量 级 进程 ， 是 程序 执行 的 最 
小 单位 。 使 用 多 线程 而 不 是 用 多 进程 去 进行 并 发 程序 的 设计 ， 征 因为 
线程 则 的 切换 和 调度 的 成 本 远 远 小 于 进程 。 


接 下 来 让 我 们 更 细致 地 观察 一 个 线程 的 生命 周期 。 我 们 可 以 绘制 
一 张 商 单 的 状态 图 来 描述 这 个 概念 ， 如 图 2.3 所 示 。 
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图 2.3 ”线程 状态 图 


线程 的 所 有 状态 都 在 Thread 中 的 State 枚 举 中 定义 ， 如 下 所 示 : 


public enum State { 
NEw, 
RUNNABLE, 
BLOCKED, 
WAITING, 
TIMED_WAITING, 
TERMINATED; 


NEW 状 态 表示 刚刚 创建 的 线程 ， 这 种 线程 还 没 开始 执行 。 等 到 线 
程 的 start() 方 法 调用 时 ， 才 表示 线程 开始 执行 。 当 线程 执行 时 ， 处 于 
RUNNABLE 状 态 ， 表 示 线 程 所 需 的 一 切 资源 都 已 经 准备 好 了 “。 如 果 线 
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状态 ， 这 时 线程 就 会 暂停 执行 ， 直 到 获得 请 求 的 锁 。WAITING 和 
TIMED_WAITING 都 表示 等 待 状态 ， 它 们 的 区 别 是 WAITING 会 进入 一 
个 无 时 间 限 制 的 等 待 ，TIMED_WAITING 会 进行 一 个 有 时 限 的 等 待 。 
那 等 待 的 线程 究竟 在 等 什么 呢 ? 一 般 来 说 ，WAITING 的 线程 正 是 在 等 
待 一 些 特殊 的 事件 。 比 如 ， 通 过 wait0 方 法 等 待 的 线程 在 等 待 notify() 方 
法 ， 而 通过 join(0) 方 法 等 待 的 线程 则 会 等 待 目标 线程 的 终止 。 一 旦 等 到 
了 期 望 的 事件 ， 线 程 就 会 再 次 执行 ， 进 入 RUNNABLE 状 态 。 当 线程 执 
行 完毕 后 ， 则 进入 TERMINATED 状 态 ， 表 示 结 束 。 


注意 : 从 NEW 状 态 出 发 后 ， 线 程 不 能 再 回 到 NEW 状 态 ， 同 理 ， 
处 于 TERMINATED 的 线程 也 不 能 再 回 到 RUNNABLE 状 态 。 


2.2 ”初始 线程 :线程 的 基本 操作 


进行 Java 并 发 设计 的 第 一 步 ， 束 古 必 须要 了 解 Java 中 为 线程 操作 
所 提供 的 一 些 API。 比 如 ， 如 何 新 建 并 且 启 动 线程 ， 如 何 终 止 线程 、 
中 断 线程 等 。 当 然 了 ， 因 为 并 行 操作 要 比 囊 行 操作 复杂 得 多 ， 于 是 ， 
围绕 着 这 些 常用 接口 ， 可 能 有 些 比较 隐 了 睡 的 “ 坑 * 等 着 你 去 踩 。 而 本 市 
也 将 尽 可 能 地 将 一 些 潜在 问题 描述 清楚 。 


2.2.1 新建 线程 


源 建 线程 很 简单 。 只 要 使 用 new 天 键 字 创建 一 个 线程 对 象 ， 并 且 
将 它 startO 起 来 即 可 。 


Thread ti=new Thread(); 


t1.start(); 
那 线 程 start0 后 ， 会 干什么 呢 ? 这 才 是 问题 的 关键 。 线 程 Thread , 


有 一 个 run( 方 法 ，start0 方 法 就 会 狐 建 一 个 线程 并 让 这 个 线程 执行 run() 
Fas 


这 里 要 注意 ， 下 面 的 代码 也 能 通过 编译 ， 也 能 正常 执行 。 但 是 ， 
却 不 能 新 建 一 个 线程 ， 而 是 在 当前 线程 中 调用 run() 方 法 ， 只 是 作为 一 
个 普通 的 方法 调用 。 


Thread ti=new Thread(); 


t1.run(); 


因此 ， 在 这 里 布 望 大 家 特别 注意 ， 调 用 start0 方 法 和 直接 调用 run0 
方法 的 区 别 。 


注意 : 不 要 用 run0 来 开启 新 线程 。 它 只 会 在 当前 线程 中 ， 串 行 执 
行 run0 中 的 代码 。 


默认 情况 下 ，Thread 的 run0 方 法 什么 都 没有 人 做， 因此， 这 个 线程 
一 启动 就 马上 结束 了 。 如 果 你 想 让 线程 做 点 什么 ， 就 必须 重 载 run() 方 
法 ， 把 你 的 “任务 * 填 进去 。 


Thread ti=new Thread(){ 
@Override 
public void run(){ 


System.out.println("Hello, I am t1"); 


ti 
ti.start(); 


上 述 代码 使 用 匿名 内 部 类 ， 重 载 了 run() 方 法 ， 并 要 求 线程 在 执行 
时 打印 *Hello, I am t12 的 字样 。 如 果 没 有 特别 的 需要 ， 都 可 以 通过 继承 
Thread， 重 载 run0 方 法 来 和 目 定 义 线程 。 但 考虑 到 Java 是 单 继 承 的 ， 也 
束 是 说 继承 本 和 号 也 是 一 种 很 宝贵 的 资源 ， 因 此 ， 我 们 也 可 以 使 用 
Runnable 接 口 来 实现 同样 的 操作 。Runnable 接 口 是 一 个 单方 法 接口 ， 
它 只 有 一 个 run0) 方 法 : 


public interface Runnable { 


public abstract void run(); 


此 外 ，Thread 类 有 一 个 非常 重要 的 构造 方法 : 


public Thread(Runnable target) 
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束 会 执行 Runnable.run() 方 法 。 实 际 上 ， 默 认 的 Thread.run0 束 是 这 么 做 
的 : 


public void run() { 
if (target != null) { 


target.run(); 


注意 : 默认 的 Thread.run0 就 是 直接 调用 内 部 的 Runnable 接 口 。 
此 ， 使 用 Runnable 接 口 告诉 线程 该 做 什么 ， 更 为 合理 。 


public class CreateThread3 implements Runnable { 
public static void main(String[] args) { 
Thread ti=new Thread(new CreateThread3() ); 


ti.start(); 


@Override 
public void run() { 


System.out.printin("Oh, I am Runnable"); 


上 述 代 码 实现 了 Runnable 接 口 ， 并 将 该 实例 传 入 Thread。 这 样 避 
免 重 载 Thread.run0) ， 单 纯 使 用 接口 来 定义 Thread， 也 是 最 常用 的 做 
1 © 


2.2.2 ”终止 线程 


一 般 来 说 ， 线 程 在 执行 完毕 后 束 会 结束 ， 无 须 手 工 关 闭 。 但 是 ， 
凡事 也 都 有 例外 。 一 些 服务 端的 后 人 台 线 程 可 能 会 前 驻 系统 ， 它 们 通 种 
` 会 正 篆 终结 。 比 如 ， 它 们 的 执行 体 本 身 就 是 一 个 大 大 的 无 穷 循 环 ， 

用 于 提供 某 些 服务 。 


那 如 何 正常 的 关闭 一 个 线程 呢 ? 查 阅 JDK， 你 不 难 发 现 Thread 提 
供 了 一 个 stop0 方 法 。 如 果 你 使 用 stop0) 方 法 ， 就 可 以 立即 将 一 个 线程 
终止 ， 非 常 方便 。 但 如 果 你 使 用 的 是 eclipse 之 类 的 IDE 写 代码 的 话 ， 就 
会 立即 发 现 stop0) 方 法 是 一 个 被 标注 为 废弃 的 方法 。 也 就 是 说 ， 在 将 
来 ，JDK 可 能 就 会 移 除 该 方法 。 


为 什么 stop0 被 废弃 而 不 推荐 使 用 呢 ? 原 因 是 stop0 方 法 太 过 于 暴 
力 ， 强 行 把 执行 到 一 半 的 线程 终止 ， 可 能 会 引起 一 些 数据 不 一 致 的 问 


题 。 
为 了 让 大 家 更 好 地 理解 本 市 内 容 ， 我 先 简单 介绍 一 些 有 关 数 据 不 


一 致 的 概念 。 假 设 我 们 在 数据 库 里 维护 着 一 张 用 户 表 ， 里 面 记 录 了 用 
户 ID 和 用 户 名 。 假 设 ， 这 里 有 两 条 记录 : 


记录 1: ID=1，NAME= 小 明 
记录 2: ID=2, NAME=/)\ 


如 果 我 们 用 一 个 User 对 象 去 保存 这 些 记录 ， 我 们 总 是 希望 这 个 对 
象 要 么 保存 记录 1， 要 么 保存 记录 2。 如 果 这 个 User 对 象 一 半 存 着 记录 
1， 男 外 一 半 存 在 记录 2， 我 想 大 部 分 人 都 会 抓 狂 吧 ! 如 果 现 在 真 的 由 
于 程序 问题 ， 出 现 了 这 人 么 一 个 怪异 的 对 象 u，u 的 ID 是 1， 但 是 u 的 Name 
是 小 王 。 那 么 ， 我 们 说 ， 在 这 种 情况 下 ， 数 据 束 已 经 不 一 怪 了 。 说 日 
了 就 是 系统 有 错误 了。 这 种 情况 是 相当 危险 的 ， 如 有 果 我 们 把 一 个 不 一 
致 的 数据 直接 写 入 了 数据 库 ， 那 么 惑 会 造成 数据 永久 地 被 令 坏 和 丢 
失 ， 后 果 不 堪 设想 。 


也 许 有 人 会 问 ， 怎 么 可 能 昵 ? 跑 得 好 好 的 系统 ， 怎 么 会 出 这 种 问 
题 呢 ? 在 单线 程 环境 中 ， 确 实 不 会 ， 但 在 并 行程 序 中 ， 如 果 考 虑 不 
周 ， 束 有 可 能 出 现 类 似 的 情况 。 不 经 思考 地 使 用 stopO0 就 有 可 能 导致 这 
种 问题 。 


Thread.stop() 方 法 在 结束 线程 时 ， 会 直接 终止 线程 ， 并 且 会 立即 释 
放 这 个 线程 所 持 有 的 锁 。 而 这 些 锁 恰 恰 是 用 来 维持 对 象 一 致 性 的 。 如 
果 此 时 ， 写 线程 写 入 数据 正 写 到 一 半 ， 并 强行 终止 ， 那 么 对 象 就 会 被 
写 坏 ， 同 时 ， 由 于 锁 已 经 被 释放 ， 男 外 一 个 等 每 该 锁 的 读 线 程 就 顺 理 
成 章 的 读 到 了 这 个 不 一 致 的 对 象 ， 悲 剧 也 残 此 发 生 。 整 个 过 程 如 图 2.4 
所 示 。 
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图 2-4 stop(0) 方 法 强行 终止 线程 导致 数据 不 一 至 


首先 ， 对 象 u 持 有 ID 和 NAME 两 个 字段 ， 简 单 起见 ， 这 里 假设 当 
ID 等 于 NAME 时 表示 对 象 是 一 致 的 ， 否 则 表示 对 象 出 销 。 写 线程 总 是 
会 将 ID 和 NAME 写 成 相同 的 值 ， 并 且 在 这 里 初始 值 都 为 0。 当 写 线程 在 
写 对 象 时 ， 读 线程 由 于 无 法 获得 锁 ， 因 此 必须 等 待 ， 所 以 读 线程 是 看 
不 见 一 个 写 了 一 半 的 对 象 的 。 当 写 线 程 写 完 ID 后 ， 很 不 幸 地 被 stop()， 
此 时 对 象 u 的 ID 为 1 而 NAME 仍 然 为 0， 处 于 不 一 致 状态 。 而 被 终止 的 写 
线程 简单 地 将 锁 释 放 ， 读 线程 争夺 到 锁 后 ， 读 取 数 据 ， 于 是 ， 读 到 了 
ID=1 而 NAME=0 的 错误 值 。 


这 个 过 程 可 以 用 以 下 代码 模拟 ， 这 里 读 线程 ReadObjectThread 在 
读 到 对 象 的 ID 和 NAME 不 一 致 时 ， 会 输出 这 些 对 象 。 而 写 线程 
ChangeObjectThread 总 是 会 写 入 两 个 相同 的 值 。 注 意 ， 代 人 码 在 第 56 行 
会 通过 stop() 方 法 强行 终止 写 线程 。 


01 public class StopThreadUnsafe { 


02 public static User u=new User(); 

03 public static class User{ 

04 private int id; 

05 private String name; 

06 public User(){ 

07 id=0; 

08 name="0"; 

09 } 

10 // 省 略 setter 和 getter 方 法 

11 @Override 

12 public String toString() { 

Lg return "User [id=" + id + ", name=" + name + 
aa 

14 } 

15 } 

16 public static class ChangeObjectThread extends Thread{ 
17 @Override 

18 public void run(){ 

19 while(true) { 

20 synchronized(u) { 

21 int v=(int) 


(System.currentTimeMillis()/1000); 


22 u.setId(v); 
23 //Oh, do sth. else 
24 try { 


25 Thread.sleep(100); 


26 } catch (InterruptedException e) { 


27 e.printStackTrace(); 

28 } 

29 u.setName(String.valueOf(v)); 

30 } 

31 Thread. yield(); 

32 } 

33 } 

34 } 

35 

36 public static class ReadObjectThread extends Thread{ 
37 @Override 

38 public void run(){ 

39 while(true) { 

40 synchronized(u) { 

41 if(u.getId() != 


Integer .parseInt(u.getName())){ 

42 System.out.println(u.toString()); 

43 i 

44 } 

45 Thread.yield(); 

46 t 

47 } 

48 } 

49 

50 public static void main(String[] args) throws 


InterruptedException { 


51 new ReadObjectThread().start(); 


52 while(true) { 

53 Thread t=new ChangeObjectThread(); 
54 t.start(); 

55 Thread.sleep(150); 

56 t.stop(); 

57 } 

58 } 

59 } 


执行 以 上 代码 ， 可 以 很 容易 得 到 类 似 如 下 输出 ，ID 和 NAME 产 生 
了 不 一 致 。 


User [1d=1425135593, name=1425135592 | 
User [1d=1425135594, name=1425135593] 


如 条 在 线 上 环境 跑 出 以 上 结果 ， 那 么 加 班 加 点 估计 是 免不了 了 ， 
因为 这 类 问题 一 旦 出 现 ， 就 很 难 排 查 ， 因 为 它们 甚至 没有 任何 错误 信 
尽 ， 也 没有 线程 堆栈 。 这 种 情况 一 旦 混杂 在 动 则 十 几 万 行 的 程序 代码 
中 时 ， 发 现 它们 束 全 赁 经 验 、 时 间 还 有 一 点 点 运气 了 。 因 此 ， 除 非 你 
很 清 私 你 在 做 什么 ， 否 则 不 要 随便 使 用 stop0 方 法 来 停止 一 个 线程 。 


那 如 果 需 要 停止 一 个 线程 时 ， 应 该 这 么 做 呢 ? 其 实 方法 很 简单 ， 
是 需要 由 我 们 目 行 决定 线程 何 时 退出 就 可 以 了 。 仍 然 用 本 例 说 明 ， 
! 需 要 将 ChangeObjectThread 线 程 增加 一 个 stopMe() 方 法 即 可 。 如 下 所 


01 public static class ChangeObjectThread extends Thread { 


02 volatile boolean stopme = false; 

03 

04 public void stopMe(){ 

05 stopme = true; 

06 } 

07 @Override 

08 public void run() { 

09 while (true) { 

10 if (stopme){ 

11 System.out.println("exit by stop me"); 
12 break; 

13 } 

14 synchronized (u) { 

15 int v = (int) (System.currentTimeMillis() / 
1000); 

16 u.setId(v); 

17 //Oh, do sth. else 

18 try { 

19 Thread.sleep(100); 

20 } catch (InterruptedException e) { 
21 e.printStackTrace(); 

22 } 

23 u.setName(String.valueOf(v)); 

24 } 

25 Thread. yield(); 


26 } 


28 } 


代码 第 2 行 ， 定义 了 一 个 标记 变量 stopme， 用 于 指示 线程 是 否 需 要 
退出 。 当 stopMe0) 方 法 被 调用 ，stopme 束 被 设置 为 tue， 此 时 ， 在 代码 
第 10 行 检测 到 这 个 改动 时 ， 线 程 惑 自然 退出 了 。 使 用 这 种 方式 退出 线 
程 ， 不 会 使 对 象 u 的 状态 出 现 错误 。 因 为 ，ChangeObjectThread 已 经 没 
有 机 会 “ 写 坏 ” 对 象 了 ， 它 总 是 会 选择 在 一 个 合适 的 时 间 终 止 线程 。 


2.2.3 ”线程 中 断 


在 Java 中 ， 线 程 中 断 是 一 种 重要 的 线程 协作 机 制 。 从 表面 上 理 
解 ， 中 断 束 是 让 目标 线程 停止 执行 的 意思 ， 实 际 上 并 非 完 全 如 此 。 在 
上 一 节 中 ， 我 们 已 经 详细 讨论 了 stop() 方 法 停止 线程 的 害处 ， 并 且 使 用 
了 一 父 目 有 的 机 制 完 善 线程 退出 的 功能 。 那 在 JDK 中 是 否 有 提供 更 强 
大 的 文 持 呢 ? 答案 是 肯定 的 ， 那 惑 是 线程 中 断 。 


严格 地 讲 ， 线 程 中 断 并 不 会 使 线程 立即 退出 ， 而 是 给 线程 发 送 一 
个 通知 ， 告 知 目标 线程 ， 有 人 和 希望 你 退出 啦 ! 至 于 目标 线程 接 到 通知 
后 如 何 处 理 ， 则 完全 由 目标 线程 目 行 决定 。 这 点 很 重要 ， 如 宁 中 断 
后 ， 线 程 立即 无 条 件 退 出 ， 我 们 区 ® 又 会 遇 到 stop0 方 法 的 老 问 题 。 


与 线程 中 断 有 关 的 ， 有 三 个 方法 ， 这 三 个 方法 看 起 来 很 像 ， 所 以 
可 能 会 引起 混淆 和 误 用 ,希望 大 家 注意 。 


public void Thread.interrupt() // 中 断 线 程 


>E 


public boolean Thread.isInterrupted() // 判断 是 否 被 中 断 


public static boolean Thread.interrupted() // 判断 是 否 被 中 断 ， 并 
清除 当前 中 断 状 态 


Thread.interrupt() 方 法 是 一 个 实例 方法 。 它 通知 目标 线程 中 断 ， 也 
瓯 是 设置 中 断 标志 位 。 中 断 标志 位 表示 当前 线程 已 经 被 中 断 了 。 
Thread.isInterrupted() 方 法 也 是 实例 方法 ， 它 判断 当前 线程 是 否 有 被 中 
Br 〈 通 过 检查 中 断 标志 位 ) 。 最 后 的 静态 方法 Thread.interrupted() 也 是 
用 来 判断 当前 线程 的 中 断 状态 ， 但 同时 会 清除 当前 线程 的 中 断 标志 位 
状态 。 


下 面 这 段 代码 对 t1 线 程 进行 了 中 断 ， 那 么 中 断后 ，t1 会 停止 执行 
my? 


public static void main(String[ ] args) throws 
InterruptedException { 
Thread ti=new Thread(){ 
@Override 
public void run(){ 
while(true) { 


Thread. yield(); 


je 
t1.start(); 
Thread.sleep(2000); 


ti.interrupt(); 


在 这 里 ， 虽 然 对 t1 进 行 了 中 断 ， 但 是 在 tl 中 并 没有 中 断 处 理 的 逻 
辑 ， 因 此 ， 即 使 Q 线 程 被 置 上 了 中 断 状 态 ， 但 是 这 个 中 断 不 会 发 生 任 
何 作用 。 


如 果 硕 望 人 在 中 断后 退出 ， 束 必须 为 它 增加 相应 的 中 断 处 理 代 
码 : 


Thread ti=new Thread(){ 
@Override 
public void run(){ 
while(true) { 
if(Thread.currentThread().isInterrupted()){ 
System.out.printin("Interruted!"); 
break; 
} 
Thread.yield(); 
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是 否 被 中 断 了 ， 如 果 是 ， 则 退出 循环 体 ， 结 束 线 程 。 这 看 起 来 与 前 面 
增加 stopme 标 记 的 手法 非常 相似 ， 但 是 中 断 的 功能 更 为 强劲 。 比 如 ， 
如 果 在 循环 体 中 ， 出 现 了 类 似 于 wait0 或 者 sleepO0 这 样 的 操作 ， 则 只 能 
通过 中 断 来 识别 了 。 


下 面 ， 先 来 了 解 一 下 Thread.sleepO) 函 数 ， 它 的 签名 如 下 : 


public static native void sleep(long millis) throws 


InterruptedException 


Thread.sleep() FEAL HAE KIRA TAI, E S h Ae 
InterruptedException li Ff ° InterruptedException \ 7212 77 AY Fe , 
tH ce Ut ee RIF ARE, SARE TEsleep(KERAY , SUR AK 
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01 public static void main(String[ ] args) throws 


InterruptedException { 


02 Thread ti=new Thread(){ 

03 @Override 

04 public void run(){ 

05 while(true){ 

06 if(Thread.currentThread().isInterrupted()){ 
07 System.out.printin("Interruted!"); 

08 break; 

09 } 

10 try { 

11 Thread.sleep( 2000) ; 

12 } catch (InterruptedException e) { 

13 System.out.printin("Interruted When 
Sleep"); 

14 // 设 置 中 断 状 态 

di5 Thread.currentThread().interrupt(); 

16 } 


17 Thread.yield(); 


19 } 

20 }; 

21 ti.start(); 

22 Thread.sleep(2000); 
23 t1.interrupt(); 

24 } 


注意 上 述 代 码 中 第 10 一 15 行 加 粗 部 分 ， 如 采 在 第 11 行 代码 处 ， 线 
程 被 中 断 ， 则 程序 会 抛 出 异常 ， 并 进入 第 13 行 处 理 。 在 catch 子 句 部 
分 ， 由 于 已 经 捕获 了 中 断 ， 我 们 可 以 立即 退出 线程 。 但 在 这 里 ， 我 们 
并 没有 这 么 做 ， 因 为 也 许 在 这 段 代 码 中 ， 我 们 还 必须 进行 后 续 的 处 
理 ， 保 证 数据 的 一 致 性 和 完整 性 ， 因 此 ， 执 行 了 Thread.interrupt() 方 法 
再 次 中 断 目 己 ， 置 上 中 断 标记 位 。 只 有 这 么 做 ， 在 第 6 行 的 中 断 检 查 
中 ， 才 能 发 现 当前 线程 已 经 被 中 断 了 。 


YER: Thread.sleep0 方 法 由 于 中 断 而 抛 出 异常 ， 此 时 ， 它 会 清除 
中 断 标记 ， 如 宁 不 加 处 理 ， 那 么 在 下 一 次 循环 开始 时 ， 束 无 法 捕 
获 这 个 中 断 ， 故 在 异常 处 理 中 ， 再 次 设置 中 断 标记 位 。 


2.2.4 SRF (wait) 和 通知 (notify) 


为 了 支持 多 线程 之 间 的 协作 ，JDK 提 供 了 两 个 非常 重要 的 接口 线 
程 等 竺 wait0 方 法 和 通知 notify0 方 法 。 这 两 个 方法 并 不 是 在 Thread 类 中 
的 ， 而 是 输出 Object 类 。 这 也 意味 着 任何 对 象 都 可 以 调用 这 两 个 方 
ka 


这 两 个 方法 的 签名 如 下 : 


public final void wait() throws InterruptedException 


public final native void notify() 


当 在 一 个 对 象 实例 上 调用 wait0 方 法 后 ， 当 前 线程 就 会 在 这 个 对 象 
等 待 。 这 是 什么 意思 呢 ? 比如 ， 线 程 A 中 ， 调 用 了 obj.wait0 方 法 ， 
那么 线程 A 就 会 停止 继续 执行 ， 而 转 为 等 待 状态 。 等 待 到 何 时 结束 
We? 线程 A 会 一 直 等 到 其 他 线程 调用 了 obj.notify0 方 法 为 止 。 这 时 ， 

obj 对 象 就 促 然 成 为 多 个 线程 之 间 的 有 效 通信 手段 。 


那 wait0 和 notify0 究 竟 是 如 何 工 作 的 呢 ? 图 2.5 展 示 了 两 者 的 工作 
过 程 。 如 果 一 个 线程 调用 了 object.wait0， 那 么 它 就 会 进入 object 对 象 的 
等 竺 队列。 这 个 等 待 队 列 中 ， 可 能 会 有 多 个 线程 ， 因 为 系统 运行 多 个 
线程 同时 等 得 某 一 个 对 象 。 当 object.notify0 被 调用 时 ， 它 就 会 从 这 个 
等 竺 队列 中 ， 随 机 选择 一 个 线程 ， 并 将 其 唤醒 。 这 里 希望 大 家 注意 的 
是 ， 这 个 选择 是 不 公平 的 ， 并 不 是 先 等 待 的 线程 会 优先 被 选 择 ， 这 个 
选择 完全 是 随机 的 。 
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图 2.5 notify0 唤 醒 等 待 的 线程 


除了 notify0) 方 法 外 ，Object 对 象 还 有 一 个 类 似 的 notifyAl10 方 法 ， 
它 和 notify0 的 功能 基本 一 致 ， 但 不 同 的 是 ， 它 会 唤醒 在 这 个 等 竺 队列 
中 所 有 等 待 的 线程 ， 而 不 是 随机 选择 一 个 。 


这 里 还 需要 强调 一 点 ，Object.wait0 方 法 并 不 是 可 以 随便 调用 的 。 
它 必须 包含 在 对 应 的 synchronzied 语 句 中 ， 无 论 是 wait0) 或 者 notify(0) 都 
需要 首先 获得 目标 对 象 的 一 个 监视 器 。 如 图 2.6 所 示 ， 显 示 了 waitO0 和 
notifyO 的 工作 流程 细节 。 其 中 T1 和 T2 表 示 两 个 线程 。T1 在 正确 执行 
wait(0) 方 法 前 ， 首 先 必 须 获 得 object 对 象 的 监视 袁 。 而 wait0 方 法 在 执行 
后 ， 会 释放 这 个 监视 器 。 这 样 做 的 目的 是 使 得 其 他 等 得 在 object 对 象 上 
的 线程 不 至 于 因为 T1 的 休眠 而 全 部 无 法 正常 执行 。 
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图 2.6 ”wait() 和 notify() 的 工作 流程 细节 


线程 T2 在 notifyO0 调 用 前 ， 也 必须 获得 object 的 监视 部。 所 幸 ， 此 
时 TI1 已 经 释放 了 这 个 监视 项。 因此 ，T2 可 以 顺利 获得 object 的 监视 
器 。 接 着 ，T2 执 行 了 notify0) 方 法 尝试 唤醒 一 个 等 待 线程 ， 这 里 假设 唤 
醒 了 T1。T1 在 被 唤醒 后 ， 要 做 的 第 一 件 事 并 不 是 执行 后 续 的 代码 ， 而 
苹 要 竹 试 重新 获得 object 的 监视 器， 而 这 个 监视 右 也 正 是 T1 在 wait() 方 
法 执行 前 所 持 有 的 那个 。 如 果 暂 时 无 法 获得 ，T1 还 必须 要 等 待 这 个 监 
视 器 。 当 监视 器 顺利 获得 后 ，T1 才 可 以 真正 意义 上 的 继续 执行 。 


为 了 方便 大 家 理解 ， 这 里 给 出 一 个 简单 地 使 用 wait0 和 notify0O 的 案 
例 : 


01 public class SimplewN { 
02 final static Object object = new Object(); 


03 

04 

05 

06 

07 
System. 
08 

09 
System. 
object 
10 

11 

12 

13 

14 
System. 
15 

16 

17 

18 

19 

20 

21 

22 
System. 


notify 


public static class T1 extends Thread{ 


public void run() 


{ 


synchronized (object) { 


out.printin(System.currentTimeMillis()+":T1 start! 


try { 


out.printin(System.currentTimeMillis()+":T1 wait 
"); 
object.wait(); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


out.printin(System.currentTimeMillis()+":T1 end!"); 


t 


$ 


public static class T2 extends Thread{ 


public void run() 


{ 


synchronized (object) { 


for 


out.printin(System.currentTimeMillis()+":T2 start! 


one 


thread"); 


23 object.notify(); 
24 


System.out.printin(System.currentTimeMillis()+":T2 end!"); 


25 try { 

26 Thread.sleep( 2000) ; 

27 } catch (InterruptedException e) { 
28 } 

29 } 

30 } 

31 } 

32 public static void main(String[] args) { 
33 Thread ti = new T1() ; 

34 Thread t2 = new T2() ; 

35 ti.start(); 

36 t2.start(); 

37 } 

38 } 


上 述 代 码 中 ， 开 启 了 两 个 线程 T1 和 T2。T1 执 行 了 objectwait0) 方 
法 。 注 意 ， 在 程序 第 6 行 ， 执 行 wait0 方 法 前 ，T1 先 申请 object 的 对 象 
锁 。 因 此 ， 在 执行 object.wait0 时 ， 它 是 持 有 object 的 锁 的 。wait(O) 方 法 
执行 后 ，T1 会 进行 等 待 ， 并 释放 object 的 锁 。T2 在 执行 notify0 之 前 也 
会 先 获 得 object 的 对 象 锁 。 这 里 为 了 让 实验 效果 明显 ， 特 意 安排 在 
notify0 执 行 之 后 ， 让 T2 休 眼 2 秒 钟 ， 这 样 做 可 以 更 明显 地 说 明 ，TI1 在 
得 到 notify0 通 知 后 ， 还 是 会 先 党 试 重新 获得 object 的 对 象 锁 。 上 壕 代码 
的 执行 结果 类 似 如 下 : 


1425224592258:T1 start! 

1425224592258:T1 wait for object 
1425224592258:T2 start! notify one thread 
1425224592258:T2 end! 

1425224594258:T1 end! 


注意 程序 打印 的 时 间 惟 信息， 可 以 看 到 ， 在 T2 通 知 T1 继 续 执 行 
后 ，T1 并 不 能 立即 继续 执行 ， 而 是 要 等 待 T2 释 放 object 的 锁 ， 并 重新 
成 功 获得 锁 后 ， 才 能 继续 执行 。 因 此 ， 加 粗 部 分 时 间 惟 的 间隔 为 2 秒 
(因为 T2 休 眼 了 2 秒 ) 。 


注意 : Object.wait0 和 Thread.sleep(0) 方 法 都 可 以 让 线程 等 待 若 干 时 
则 。 除 了 wait() 可 以 被 唤醒 外 ， 男 外 一 个 主要 区 别 束 是 wait(0 方 法 
会 释放 目标 对 象 的 锁 ， 而 Thread.sleep(0) 方 法 不 会 释放 任何 资源 。 


2.2.5” 挂 起 (suspend) 和 继续 执行 
(resume) 线程 


如 果 你 阅读 JDK 有 关 Thread 类 的 API 文 档 ， 可 能 还 会 发 现 两 个 看 起 
来 非常 有 用 的 接口 ， 即 线程 挂 起 (suspend) 和 继续 执行 (resume) 
这 两 个 操作 是 一 对 相反 的 操作 ， 被 挂 起 的 线程 ， 必 须要 等 到 resume() 
操作 后 ， 才 能 继续 指定 。 乍 看 之 下 ， 这 对 操作 斌 像 Thread.stop0 方 法 一 
样 好 用 。 但 如 果 你 仔细 阅读 文档 说 明 ， 会 发 现 它 们 也 早已 被 标注 为 废 
弃 方 法 ， 并 不 推荐 使 用 。 


不 推荐 使 用 suspend0 去 挂 起 线程 的 原因 ， 是 因为 suspend0 在 导致 
线程 暂停 的 同时 ， 并 不 会 去 释放 任何 锁 资 源 。 此 时 ， 其 他 任何 线程 想 


要 访问 被 它 暂 用 的 锁 时 ， 都 会 被 牵连 ， 导 致 无 法 正常 继续 运行 (如 图 
2.7 所 示 ) 。 直 到 对 应 的 线程 上 进行 了 resume() 操 作 ， 被 挂 起 的 线程 才 
能 继续 ， 从 而 其 他 所 有 阻塞 在 相关 锁 上 的 线程 也 可 以 继续 执行 。 但 
是 ， 如 果 resume() 操 作 意 外 地 在 suspend0O) 前 就 执行 了 ， 那 么 被 挂 起 的 线 
程 可 能 很 难 有 机 会 被 继续 执行 。 并 且 ， 更 严重 的 是 : 它 所 占用 的 锁 不 
会 被 释放 ， 因 此 可 能 会 导致 整个 系统 工作 不 正常 。 而 且 ， 对 于 被 挂 起 
的 线程 ， 从 它 的 线程 状态 上 看 ， 居 然 还 是 Runnable， 这 也 会 严重 影响 
我 们 对 系统 当前 状态 的 判断 。 
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图 2.7 ”suspend() 方 法 导致 线程 进入 类 似 死 锁 的 状态 


为 了 方便 大 家 理解 suspend0 的 问题 ， 这 里 准备 一 个 简单 的 程序 。 
演示 了 这 种 情况 : 
01 public class BadSuspend { 
02 public static Object u = new Object(); 
03 static ChangeObjectThread t1 = new 
ChangeObjectThread("t1i"); 


04 static ChangeObjectThread t2 = new 
ChangeObjectThread("t2"); 


05 


06 public static class ChangeObjectThread extends Thread { 
07 public ChangeObjectThread(String name){ 

08 super . setName (name); 

09 } 

10 @Override 

11 public void run() { 

12 synchronized (u) { 

13 System.out.println("in "+getName()); 

14 Thread.currentThread().suspend(); 

15 } 

16 } 

17 } 

18 

19 public static void main(String[] args) throws 


InterruptedException { 


20 ti.start(); 

21 Thread.sleep(100); 
22 t2.start(); 

23 ti.resume(); 

24 t2.resume(); 

25 t1.join(); 

26 t2.join(); 

27 } 


执行 上 述 代 码 ， 开 局 tL 和 刀 两 个 线程 。 他 们 会 在 第 12 行 通过 对 象 
锁 u 实 现 对 临界 区 的 访问 。 线 程 tL 和 t2 启 动 后 ， 在 主 函 数 中 ， 第 23 一 24 
行 ， 对 其 进行 resume0。 目 的 是 让 他 们 得 以 继续 执行 。 接 着 ， 主 函数 
等 待 着 两 个 线程 的 结束 。 


执行 上 述 代码 后 ， 我 们 可 能 会 得 到 以 下 输出 : 


in t1 


in t2 


这 表明 两 个 线程 先后 进入 了 临界 区 。 但 是 程序 不 会 退出 。 而 是 会 
挂 起 。 使 用 jstack 命 令 打印 系统 的 线程 信息 可 以 看 到 : 


Mp 


"t2" #9 prio=5 os_prio=0 tid=0x15c85c00 nid=0xiddc runnable 
[Ox15f2F000] 
java.lang.Thread.State: RUNNABLE 
at java.lang.Thread.suspendO(Native Method) 
at java.lang.Thread.suspend(Thread.java:1029 ) 
at 

geym.conc.ch2.suspend.BadSuspend$ChangeObjectThread. run(BadSusp 
end. java:16) 

- locked <0x048b2e58> (a java.lang.Object) 
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它 的 线程 状态 确实 是 RUNNABLE ， 这 很 有 可 能 使 我 们 误 判 当前 系统 的 
状态 。 同 时 ， 虽 然 主 函数 中 已 经 调用 了 resume0， 但 是 由 于 时 间 移 后 
顺序 的 缘故 ， 那 个 resume 并 没有 生效 ! 这 束 导 致 了 线程 忆 被 永远 挂 
起 ， 并 且 永 远 占 用 了 对 象 u 的 锁 。 这 对 于 系统 来 说 极 有 可 能 是 致命 的 。 


如 果 需 要 一 个 比较 可 靠 的 suspend0 函 数 ， 那 应 该 怎么 办 呢 ? 回想 
一 下 上 一 三 中 提 到 的 wait() 和 notify0 方 法 ， 这 也 不 是 一 件 难 事 。 下 面 的 
代码 就 给 出 了 一 个 利用 wait() 和 notify(0) 方 法 ， 在 应 用 层面 实现 suspend() 
和 resume() 功 能 的 例子 。 


01 public class GoodSuspend { 


02 public static Object u = new Object(); 
03 

04 public static class ChangeObjectThread extends Thread { 
05 volatile boolean suspendme = false; 
06 

07 public void suspendMe() { 

08 suspendme = true; 

09 } 

10 

11 public void resumeMe(){ 

12 suspendme=false; 

13 synchronized (this){ 

14 notify(); 

15 } 

16 } 

17 @Override 

18 public void run() { 

19 while (true) { 

20 

21 synchronized (this) { 


22 while (suspendme) 


23 
24 
25 
26 
27 
28 
29 
30 
31 


try { 
wait(); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


synchronized (u) { 


System.out.printin( "in 


ChangeObjectThread") ; 


32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 


} 
Thread.yield(); 


public static class ReadobjectThread extends Thread { 
@Override 
public void run() { 
while (true) { 
synchronized (u) { 


System.out.printin( "in 


ReadObjectThread"); 


44 
45 
46 
47 


} 
Thread.yield(); 


50 public static void main(String[] args) throws 


InterruptedException { 


51 ChangeObjectThread ti = new ChangeObjectThread(); 
52 ReadObjectThread t2 = new ReadObjectThread(); 
53 ti.start(); 

54 t2.start(); 

55 Thread.sleep(1000); 

56 t1.suspendMe(); 

57 System.out.println("suspend ti 2 sec"); 

58 Thread.sleep(2000); 

59 System.out.println("resume ti"); 

60 t1.resumeMe(); 

61 } 

62 } 


在 代码 第 5 行 ， 给 出 一 个 标记 变量 suspendme， 表 示 当 前 线程 是 否 
被 挂 起 。 同 时 ， 增 加 了 suspendMe0 和 resumeMe0 两 个 方法 ， 分 别 用 于 
挂 起 线程 和 继续 执行 线程 。 


在 代码 第 21~28 行 ， 线 程 会 先 检查 自己 是 否 被 挂 起 ， 如 果 是 ， 则 
执行 wait() 方 法 进行 等 待 。 否 则 ， 则 进行 正常 的 处 理 。 当 线程 继续 执行 
时 ，resumeMe() 方 法 被 调用 (代码 第 11~-16 行 ) ， 线 程 tL 得 到 一 个 继 
续 执行 的 notify0 通 知 ， 并 且 清 除了 挂 起 标记 ， 从 而 得 以 正常 执行 。 


2.2.6 “等待 线程 结束 (join) 和 谦让 
(yield) 


在 很 多 情况 下 ， 线 程 之 间 的 协作 和 人 与 人 之 间 的 协作 非常 类 似 。 
一 种 非常 钊 见 的 合作 方式 吏 是 分 工 合作 。 以 我 们 非常 束 悉 的 软件 开发 
为 例 ， 在 一 个 项 目 进行 时 ， 总 是 应 该 有 几 位 号 称 是 “需求 分 析 师 ”的 同 
事 ， 先 对 系统 的 需求 和 功能 点 进行 整理 和 总 结 ， 然 后 ， 以 书面 形式 给 
出 一 份 需求 说 明 或 者 类 似 的 参考 文档 ， 然 后 ， 软 件 设计 师 、 人 研发 工程 
师 才 会 一 拥 而 上 ， 进 行 软 件 开 发 。 如 有 果 缺 少 需求 分 析 师 的 工作 输出 ， 
那么 软件 研发 的 难度 可 能 会 比较 大 。 因 此 ， 作 为 一 名 软件 研发 人 员 ， 
总 是 喜欢 等 行 需求 分 析 师 完成 他 应 该 完成 的 任务 后 ， 才 愿意 投 号 工 
作 。 简 单 地 说 ， 吏 是 研发 人 员 需 要 等 待 需求 分 析 师 完成 他 的 工作 ， 然 
后 ， 才 能 进行 研发 。 


将 这 个 关系 对 应 到 多 线程 应 用 中 ， 很 多 时 候 ， 一 个 线程 的 输入 可 
能 非常 依赖 于 另外 一 个 或 者 多 个 线程 的 输出 ， 此 时 ， 这 个 线程 吏 需 要 
等 行 依赖 线程 执行 完毕 ， 才 能 继续 执行 。JDK 提 供 了 join0 操 作 来 实现 
这 个 功能 ， 如 下 所 示 ， 显 示 了 2 个 join0 方 法 : 


public final void join() throws InterruptedException 
public final synchronized void join(long millis) throws 


InterruptedException 


第 一 个 join0 方 法 表示 无 限 等 每 ， 它 会 一 直 阻塞 当前 线程 ， 直 到 目 
标 线程 执行 完毕 。 第 二 个 方法 给 出 了 一 个 最 大 等 待 时 间 ， 如 末 超 过 给 
定时 间 目 标 线程 还 在 执行 ， 当 前 线程 也 会 因为 “等 不 及 了 ”， 而 继续 往 
PAT. 


英文 join 的 翻译 ， 通 第 是 加 入 的 意思 。 在 这 里 感觉 也 非常 贴切 。 
因为 一 个 线程 要 加 入 男 外 一 个 线程 ， 那么 最 好 的 方法 束 是 等 着 它 一 起 
Fg 


这 里 提供 一 个 简单 点 的 join0 实 例 ， 供 大 家 参考 : 


public class JoinMain { 
public volatile static int 1=0; 
public static class AddThread extends Thread{ 
@Override 
public void run() { 


for (1=0;1<10000000; i++); 


public static void main(String[] args) throws 
InterruptedException { 
AddThread at=new AddThread(); 
at.start(); 
at.join(); 


System.out.println(1); 


主 函 数 中 ， 如 采 不 使 用 join0 等 待 AddThread， 那 么 得 到 的 i 很 可 能 
是 0 或 者 一 个 非常 小 的 数字 。 因 为 AddThread 还 没 开 始 执行 ，i 的 值 就 已 
经 被 输出 了 。 但 在 使 用 join0 方 法 后 ， 表 示 主 线程 愿意 等 待 AddThread 
执行 完毕 ， 跟 着 AddThread 一 起 往 前 走 ， 故 在 join0 返 回 时 ，AddThread 
已 经 执行 完成 ， 故 ji 总 是 10000000。 


有 关 join0 ， 我 还 想 再 补充 一 点 ，join0 的 本 质 是 让 调用 线程 wait0) 
在 当前 线程 对 象 实例 上 。 下 面 是 JDK 中 join0 实 现 的 核心 代码 片段 : 


while (isAlive()) { 
wait(Q); 


可 以 看 到 ， 它 让 调用 线程 在 当前 线程 对 象 上 进行 等 待 。 当 线程 执 
行 完 成 后 ， 被 等 待 的 线程 会 在 退出 前 调用 notifyAl10 通 知 所 有 的 等 待 线 
程 继 续 执 行 。 因 此 ， 值 得 注意 的 一 点 是 : 不 要 在 应 用 程序 中 ， 在 
Thread 对 象 实例 上 使 用 类 似 wait0 或 者 notify0O 等 方法 ， 因 为 这 很 有 可 能 
会 影响 系统 API 的 工作 ， 或 者 被 系统 API 所 影响 。 


另外 一 个 比较 有 趣 的 方法 ， 是 Thread.yield()， 它 的 定义 如 下 : 


public static native void yield(); 


这 是 一 个 静态 方法 ， 一 旦 执行 ， 它 会 使 当前 线程 让 出 CPU。 但 要 
注意 ， 让 出 CPU 并 不 表示 当前 线程 不 执行 了 。 当 前 线程 在 让 出 CPU 
后 ， 还 会 进行 CPU 资 源 的 争夺 ， 但 是 是 否 能 够 再 次 被 分 配 到 ， 就 不 一 
定 了 。 因 此 ， 对 Thread.yield0 的 调用 就 好 像 是 在 说 : 我 已 经 完成 一 些 
最 重要 的 工作 了 ， 我 应 该 是 可 以 休息 一 下 了 ， 可 以 给 其 他 线程 一 些 工 
作 机 会 啦 ! 


如 果 你 觉得 一 个 线程 不 那么 重要 ， 或 者 优先 级 非常 低 ， 而 且 又 害 
怕 它 会 占用 太 多 的 CPU 资源， 那么 可 以 在 适当 的 时 候 调 用 
Thread.yield()， 给 予 其 他 重要 线程 更 多 的 工作 机 会 。 


2.3 volatile 与 Java WF ta W 
(JMM) 


之 前 已 经 简单 介绍 了 Java 内 存 模 型 (JMM) ，Java 内 存 模型 都 是 
图 绕 着 原子 性 、 有 序 性 和 可 见 性 展开 的 。 大 家 可 以 先 回顾 一 下 上 一 章 
中 的 相关 内 容 。 为 了 在 适当 的 场合 ， 确 保 线程 间 的 有 序 性 、 可 见 性 和 
原子 性 。Java 使 用 了 一 些 特殊 的 操作 或 者 关键 字 来 申明 、 告 诉 虚拟 
机 ， 在 这 个 地 方 ， 要 尤其 注意 ， 不 能 随意 变动 优化 目标 指令 。 关 键 字 
volatile 束 是 其 中 之 一 。 


如 果 你 查阅 一 下 英文 字典 ， 有 关 volatile 的 解释 ， 你 会 得 到 最 第 用 
的 解释 十“ 易 变 的 ， 不 稳定 的 "。 这 也 正 是 使 用 volatile 关 键 字 的 语义 。 


当 你 用 volatile 去 申明 一 个 变量 时 ， 就 等 于 告诉 了 虚拟 机 ， 这 个 变 
量 极 有 可 能 会 被 某 些 程序 或 者 线程 修改 。 为 了 确保 这 个 变量 被 修改 
后 ， 应 用 程序 范围 内 的 所 有 线程 都 能 够 “看 到 ”这 个 改动 ， 虚 拟 机 束 必 
须 采 用 一 些 特殊 的 手段 ， 保 证 这 个 变量 的 可 见 性 等 特点 。 


比如 ， 根 据 编译 右 的 优化 规则 ， 如 采 不 使 用 volatile 申 明 变 量 ， 那 
么 这 个 变量 被 修改 后 ， 其 他 线程 可 能 并 不 会 被 通知 到 ， 甚 至 在 别 的 线 
程 中 ， 看 到 变量 的 修改 顺序 都 会 是 反 的 。 但 一 旦 使 用 volatile， 虚 拟 机 
就 会 特别 小 心地 处 理 这 种 情况 。 


大 家 应 该 对 上 一 章 中 介绍 原子 性 时 ， 给 出 的 MultiThreadLong 案 例 
还 记忆 犹 新 吧 ! RE, 没有 人 愿意 就 这 么 把 数据 “ 写 坏 ”。 那 这 种 情 
况 ， 应 该 怎么 处 理 才 能 保证 每 次 写 进去 的 数据 不 坏 呢 ? 最 简单 的 一 种 


方法 就 是 加 入 volatile 申 明 ， 告 诉 编译 侨 ， 这 个 long 型 数据 ， 你 要 格外 
小 心 ， 因 为 他 会 不 断 地 被 修改 。 


下 面 的 代码 片段 显示 了 volatile 的 使 用 ， 限 于 篇 幅 ， 这 里 不 再 给 出 
完整 代码 : 


public class MultiThreadLong { 
public volatile static long t=0; 
public static class ChangeT implements Runnable{ 


private long to; 


从 这 个 案例 中 ， 我 们 可 以 看 到 ，volatile 对 于 保证 操作 的 原子 性 是 
有 非常 大 的 帮助 的 。 但 是 需要 注意 的 是 ，volatile 并 不 能 代替 锁 ， 它 也 
无 法 保证 一 些 复 合 操作 的 原子 性 。 比 如 下 面 的 例子 ， 通 过 volatile 是 无 
法 保证 it+ 的 原子 性 操作 的 : 


01 static volatile int i=0; 


02 public static class PlusTask implements Runnable{ 


03 @Override 

04 public void run() { 

05 for(int k=0;k<10000;k++) 

06 it; 

07 } 

08 } 

09 

10 public static void main(String[ ] args) throws 


InterruptedException { 


11 Thread[] threads=new Thread[10]; 


12 for(int i=0;i<10;i++){ 

Ls threads[i]=new Thread(new PlusTask()); 
14 threads[i].start(); 

15 } 

16 for(int i=0;i<10;i++){ 

17 threads[i].join(); 

18 } 

19 

20 System.out.println(1); 

21 } 


执行 上 述 代码 ， 如 果 第 6 行 it+ 是 原子 性 的 ， 那 么 最 终 的 值 应 该 
100000 (10 个 线程 各 累加 10000 次 ) 。 但 实际 上 ， 上 述 代码 的 输出 总 
会 小 于 100000 。 


H 
AE 

日 
AE 


此 外 ，volatile 也 能 保证 数据 的 可 见 性 和 有 序 性 。 下 面 再 来 看 一 个 
简单 的 例子 : 


01 public class NoVisibility { 


02 private static boolean ready; 

03 private static int number; 

04 

05 private static class ReaderThread extends Thread { 
06 public void run() { 

07 while (!ready); 

08 System.out.println(number); 


09 i 


12 public static void main(String[] args) throws 


InterruptedException { 


le! new ReaderThread().start(); 
14 Thread.sleep(1000); 

15 number = 42; 

16 ready = true; 

17 Thread.sleep(10000) ; 

18 } 

19 } 


上 述 代码 中 ，ReaderThread 线 程 只 有 在 数据 准备 好 时 (ready 为 
true) ， 才 会 打印 number 的 值 。 它 通过 ready 变 量 判 断 是 否 应 该 打印 。 
在 主线 程 中 ， 开 局 ReaderThread 后 ， 就 为 number 和 ready 赋 值 ， 并 期 望 
ReaderThread 能 够 看 到 这 些 变 化 并 将 数据 输出 。 


在 虚拟 机 的 Client 模 式 下 ， 由 于 JIT 并 没有 做 足够 的 优化 ， 在 主线 
程 修改 ready 变 量 的 状态 后 ，ReaderThread 可 以 发 现 这 个 改动 ， 并 退出 
程序 。 但 是 在 Server 模 式 下 ， 由 于 系统 优化 的 结果 ，ReaderThread 线 程 
无 法 “看 到 ”主线 程 中 的 修改 ， 导 致 ReaderThread 永 远 无 法 退出 (因为 
代码 第 7 行 判 断 永远 不 会 成 立 ) ， 这 显然 不 是 我 们 想 看 到 的 结果 。 这 个 
问题 就 是 一 个 典型 的 可 见 性 问题 。 


WER: 可 以 使 用 Java 虚 拟 机 参数 -server 切 换 到 Server 模 式 。 


和 原子 性 问题 一 样 ， 我 们 只 要 人 徐 单 地 使 用 volatile 来 申明 ready 变 
量 ， 告 诉 Java 虚 拟 机 ， 这 个 变量 可 能 会 在 不 同 的 线程 中 修改 。 这 样 ， 


就 可 以 顺利 解决 这 个 问题 了 。 


2.4 分 门 别 类 的 管理 : 线程 组 


在 一 个 系统 中 ， 如 果 线 程 数量 很 多 ， 而 且 功 能 分 配 比较 明确 ， 残 
可 以 将 相同 功能 的 线程 放置 在 一 个 线程 组 里 。 打 个 比方 ， 如 果 你 有 一 
个 人 苹果， 你 束 可 以 把 它 拿 在 手 里 ， 但 是 如 琳 你 有 十 个 人 苹果， 你 忠 最 好 
还 有 一 个 篮子 ， 否 则 不 方便 携带 。 对 于 多 线程 来 说 ， 也 是 这 个 道理 。 
想 要 轻松 处 理 几 十 个 甚至 上 百 个 线程 ， 最 好 还 是 将 它们 部 狠 进 对 应 的 
Tras 


线程 组 的 使 用 非常 简单 ， 如 下 : 


01 public class ThreadGroupName implements Runnable { 


02 public static void main(String[] args) { 

03 ThreadGroup tg = new ThreadGroup("PrintGroup"); 

04 Thread t1 = new Thread(tg, new ThreadGroupName(), 
HE ha 

05 Thread t2 = new Thread(tg, new ThreadGroupName(), 
EED 

06 t1.start(); 

07 t2.start(); 

08 System.out.println(tg.activeCount()); 

09 tg.list(); 

10 } 

11 

12 @Override 


13 public void run() { 


14 String 


groupAndName=Thread.currentThread().getThreadGroup( ).getName() 


15 + "-" + Thread.currentThread().getName(); 
16 while (true) { 

17 System.out.println("I am " + groupAndName) ; 
18 Gye 

19 Thread.sleep( 3000); 

20 } catch (InterruptedException e) { 

21 e.printStackTrace(); 

22 } 

23 } 

24 } 

25 } 


上 述 代 码 第 3 行 ， 建 立 一 个 名 为 “PrintGroup” 的 线程 组 ， 并 将 T1 和 
T2 两 个 线程 加 入 这 个 组 中 。 第 8、9 两 行 ， 展示 了 线程 组 的 两 个 重要 的 
功能 ，activeCount() 可 以 获得 活动 线程 的 总 数 ， 但 由 于 线程 是 动态 的 ， 
因此 这 个 值 只 是 一 个 估计 值 ， 无 法 确定 精确 ，list0 方 法 可 以 打印 这 个 
线程 组 中 所 有 的 线程 信息 ， 对 调试 有 一 定 帮 助 。 代 码 中 第 4、5 两 行 创 
建 了 两 个 线程 ， 使 用 Thread 的 构造 函数 ， 指 定 线程 所 属 的 线程 组 ， 将 
线程 和 线程 组 关联 起 来 。 


线程 组 还 有 一 个 值得 注意 的 方法 stop0， 它 会 停止 线程 组 中 所 有 的 
线程 。 这 看 起 来 是 一 个 很 方便 的 功能 ， 但 是 它 会 遇 到 和 Thread.stopO 相 
同 的 问题 ， 因 此 使 用 时 也 需要 格外 谨慎 。 


此 外 ， 对 于 编码 习惯 ， 我 还 想 再 多 说 几 句 。 强 烈 建 议 大 家 在 创建 
线程 和 线程 组 的 时 候 ， 给 它们 取 一 个 好 听 的 名 字 。 对 于 计算 机 来 说 ， 


也 许 名 字 并 不 重要 ， 但 是 在 系统 出 现 问题 时 ， 你 很 有 可 能 会 导出 系统 
内 所 有 线程 ， 你 拿 到 的 如 果 是 一 连 串 的 Thread-0、Thread-1、Thread- 
2， 我 想 你 一 定 会 抓 狂 。 但 取而代之 ,你 看 到 的 如 有 果 是 类 似 
HttpHandler、FTPService 这 样 的 名 字 ， 会 让 你 心情 倍 更 。 


25 驻守 后 台 : 守护 线程 


(Daemon) 


守护 线程 是 一 种 特殊 的 线程 ， 就 和 它 的 名 字 一 样 ， 它 是 系统 的 守 
护 者 ， 在 后 台 默 默 地 完成 一 些 系统 性 的 服务 ， 比 如 垃圾 回收 线程 、JIT 
线程 就 可 以 理解 为 守护 线程 。 与 之 相对 应 的 是 用 户 线程 ， 用 户 线程 可 
以 认为 是 系统 的 工作 线程 ， 它 会 完成 这 个 程序 应 该 要 完成 的 业务 操 
作 。 如 果 用 户 线 程 全 部 结束 ， 这 也 意味 着 这 个 程序 实际 上 无 事 可 做 
了 。 和 守护 线程 要 守护 的 对 象 已 经 不 存在 了 ， 那 么 整个 应 用 程序 怠 目 然 
应 该 结束 。 因 此 ， 当 一 个 Java 应 用 内 ， 只 有 守护 线程 时 ，Java 虚 拟 机 
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下 面 商 单 地 看 一 下 守护 线程 的 使 用 : 


01 public class DaemonDemo { 


02 public static class DaemonT extends Thread{ 

03 public void run(){ 

04 while(true){ 

05 System.out.println("I am alive"); 
06 try { 

07 Thread.sleep(1000); 

08 } catch (InterruptedException e) { 
09 e.printStackTrace(); 

10 } 


11 } 


14 public static void main(String[] args) throws 


InterruptedException { 


15 Thread t=new DaemonT(); 
16 t.setDaemon(true); 

17 t.start(); 

18 

19 Thread.sleep(2000); 

20 } 

21 } 


上 述 代 码 第 16 行 ， 将 线程 t 设 置 为 守护 线程 。 这 里 注意 ， 设 置 守 护 
线程 必须 在 线程 start(0) 之 前 设置 ， 否 则 你 会 得 到 一 个 类 似 以 下 的 异 币 ， 
告诉 你 守护 线程 设置 失败 。 但 是 你 的 程序 和 线程 依然 可 以 正常 执行 。 
只 是 被 当做 用 户 线程 而 已 。 因 此 ， 如 末 不 小 心 忽 略 了 下 面 的 异常 信 
思 ， 你 就 很 可 能 察觉 不 到 这 个 错误 。 那 你 束 会 证 异 为 什么 程序 永远 俘 
AN BOR T We’? 


Exception in thread "main" 
java.lang.IllegalThreadStateException 
at java.lang.Thread.setDaemon(Thread. java:1367 ) 


at geym.conc.ch2.daemon.DaemonDemo.main(DaemonDemo. java: 20) 


在 这 个 例子 中 ， 由 于 t 倍 设置 为 守护 线程 ， 系 统 中 只 有 主线 程 main 
为 用 户 线程 ， 因 此 在 main 线 程 休 眠 2 秒 后 退出 时 ， 人 整个 程序 也 随 之 结 
束 。 但 如 果 不 把 线程 设置 为 守护 线程 ，main 线 程 结束 后 ，t 线 程 还 会 
不 停 地 打印 ， 永 远 不 会 结束 。 


2.6” 先 干 重要 的 事 : 线程 优先 级 


Java 中 的 线程 可 以 有 自己 的 优先 级 。 优 先 级 高 的 线程 在 竞争 资源 
时 会 更 有 优势 ， 更 可 能 抢占 资源 ， 当 然 ， 这 只 是 一 个 概率 问题 。 如 果 
运气 不 好 ， 高 优先 级 线程 可 能 也 会 抢占 失败 。 由 于 线程 的 优 移 级 调度 
和 底层 操作 系统 有 密切 的 关系 ， 在 各 个 平台 上 表现 不 一 ， 并 且 这 种 优 
先 级 产生 的 后 果 也 可 能 不 容易 预测 ， 无 法 精准 控制 ， 比 如 一 个 低 优先 
级 的 线程 可 能 一 直 抢占 不 到 货源 ， 从 而 始终 无 法 运行 ， 而 产生 饥 场 
(虽然 优先 级 低 ， 但 是 也 不 能 饿 死 它 呀 ) 。 因 此 ， 在 要 求 严 格 的 场 
合 ， 还 是 需要 目 己 在 应 用 层 解决 线程 调度 问题 。 


在 Java 中 ， 使 用 1 到 10 表 示 线 程 优先 级 。 一 般 可 以 使 用 内 置 的 三 个 
静 仿 标量 表示 : 


public final static int MIN_PRIORITY = 1; 
public final static int NORM_PRIORITY = 5; 


public final static int MAX_PRIORITY = 10; 


数字 越 大 则 优先 级 越 高 ， 但 有 效 范围 在 1 到 10 之 间 。 下 面 的 代码 展 
示 了 优先 级 的 作用 。 高 优先 级 的 线程 倾 癌 于 更 快 地 完成 。 


01 public class PriorityDemo { 


02 public static class HightPriority extends Thread{ 
03 static int count=0; 
04 public void run(){ 


05 while(true){ 


06 synchronized(PriorityDemo.class) { 


07 count++; 
08 if (count > 10000000) { 
09 System.out.printin("HightPriority is 


complete"); 


10 break; 

11 上 

12 } 

13 } 

14 } 

iS } 

16 public static class LowPriority extends Thread{ 
aly static int count=0; 

18 public void run(){ 

19 while(true){ 

20 synchronized(PriorityDemo.class) { 
21 count++; 

22 if (count > 10000000) { 

23 System.out.println("LowPriority is 


complete"); 

24 break; 
25 } 

26 } 

27 } 

28 } 

29 } 

30 


31 public static void main(String[] args) throws 


InterruptedException { 


32 Thread high=new HightPriority(); 

33 LowPriority low=new LowPriority(); 

34 high.setPriority(Thread.MAX_PRIORITY); 
35 low.setPriority(Thread.MIN_PRIORITY); 
36 low.start(); 

37 high.start(); 

38 } 

39 } 


上 述 代码 定义 两 个 线程 ， 分 别 为 Hightpriority 设 置 为 高 优先 级 ， 
LowPriority 为 低 优先 级 。 让 它们 完成 相同 的 工作 ， 也 就 是 把 count 从 0 
加 到 10000000。 完 成 后 ， 打 印信 息 给 一 个 提示 ， 这 样 我 们 就 知道 谁 先 
完成 工作 了 。 这 里 要 注意 ， 在 对 count 标 加 前 ， 我 们 使 用 synchronized 
产生 了 一 次 资源 竞争 。 目 的 是 使 得 优先 级 的 差异 表现 得 更 为 明显 。 


大 家 可 以 尝试 执行 上 述 代码 ， 可 以 看 到 ， 高 优先 级 的 线程 在 大 部 
分 情况 下 ， 都 会 首先 完成 任务 (就 这 段 代码 而 言 ， 试 运行 多 次 ， 
HightPriority 总 是 比 LowPriority 快 ， 但 这 不 能 保证 在 所 有 情况 下 ， 一 定 
都 是 这 样 ) 。 


27 线程 安全 的 概念 与 


synchronized 


并 行程 序 开发 的 一 大 关注 重点 就 是 线程 安全 。 一 般 来 说 ， 程 序 并 
行 化 是 为 了 获得 更 高 的 执行 效率 ， 但 前 提 是 ， 高 效率 不 能 以 牺牲 正确 
性 为 代价 。 如 采 程 序 并 行 化 后 ， 连 基本 的 执行 结果 的 正确 性 都 无 法 保 
证 ， 那 么 并 行程 序 本 吴 也 吏 没 有 任何 意义 了 。 因 此 ， 线 程 安全 丈 是 并 
行程 序 的 根本 和 根基 。 大 家 还 记得 那个 多 线程 读 写 long 型 数据 的 案例 
吧 ! 这 就 是 一 个 典型 的 反例 。 但 在 使 用 volatile 关 键 字 后 ， 这 种 错误 的 
情况 有 所 改善 。 但 是 ，volatile 并 不 能 真正 的 保证 线程 安全 。 它 只 能 确 
你 一 个 线程 修改 了 数据 后 ， 其 他 线程 能 够 看 到 这 个 改动 。 但 当 两 个 线 
程 同时 修改 某 一 个 数据 时 ， 却 依然 会 产生 冲突 。 


下 面 的 代码 演示 了 一 个 计数 姻 ， 两 个 线程 同时 对 i 进行 累加 操作 ， 
各 执行 10000000 次 。 我 们 希望 的 执行 结果 当然 是 最 终 i 的 值 可 以 达到 
20000000， 但 事实 并 非 总 是 如 此 。 如 采 你 多 执行 几 次 下 述 代 码 ， 你 会 
发 现 ， 在 很 多 时 候 ，i 的 最 终 值 会 小 于 20000000。 这 就 是 因为 两 个 线程 
同时 对 ij 进行 写 入 时 ， 其 中 一 个 线程 的 结果 会 覆盖 另外 一 个 (虽然 这 个 
时 候 i 被 声明 为 volatile 变 量 ) 


01 public class AccountingVol implements Runnable{ 


02 static AccountingVol instance=new AccountingVol(); 
03 static volatile int i=0; 
04 public static void increase(){ 


05 cia, 


06 
07 
08 
09 
10 
11 
12 
13 


} 


@Override 
public void run() { 
for(int j=0; j<10000000; j++){ 


increase(); 


public static void main(String[] args) 


InterruptedException { 


14 
15 
16 


17 
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Thread ti=new Thread(instance) ; 
Thread t2=new Thread(instance) ; 
ti.start();t2.start(); 
t1.join();t2.join(); 


System.out.println(i); 


throws 


图 2.8 展 示 了 这 种 可 能 的 冲突 ， 如 采 在 代码 中 发 生 了 类 似 的 情况 ， 
o 线程 1 和 线程 2 同时 读 取 i 为 0， 并 各 目 计 


算得 到 i=1， 并 先后 写 入 这 个 结 采 ， 因 此， 虽然 it+ 被 执行 了 2 次 ,但 古 
实际 的 值 只 增加 了 1。 


> 4 -n 
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R28 ”多 线程 的 写 入 冲突 


要 从 根本 上 人 解决 这 个 问题 ， 我 们 就 必须 保证 多 个 线程 在 对 i 进行 操 
作 时 完全 同步 。 也 就 是 说 ， 当 线程 A 在 写 入 时 ， 线 程 B 不 仪 不 能 写 ， 同 
时 也 不 能 读 。 因 为 在 线程 A 写 完 之 前 ， 线 程 B 读 取 的 一 定 是 一 个 过 期 数 
据 。Java 中 ， 提 供 了 一 个 重要 的 天 键 字 synchronized 来 实现 这 个 功能 。 


关键 字 synchronized 的 作用 是 实现 线程 间 的 同步 。 它 的 工作 是 对 同 
步 的 代码 加 锁 ， 使 得 每 一 次 ， 只 能 有 一 个 线程 进入 同步 块 ， 从 而 保证 
线程 间 的 安全 性 〈 也 就 是 说 在 上 述 代码 的 第 5 行 ， 每 次 应 该 只 有 一 个 线 
程 可 以 执行 ) 


关键 字 synchronized 可 以 有 多 种 用 法 。 这 里 做 一 个 简单 的 整理 。 


指定 加 锁 对 象 : 对 给 定 对 象 加 锁 ， 进 入 同步 代码 前 要 获得 给 定 
对 象 的 锁 。 

直接 作用 于 实例 方法 : 相当 于 对 当前 实例 加 锁 ， 进 入 同步 代码 
前 要 获得 当前 实例 的 锁 。 


。 直接 作用 于 静态 方法 : 相当 于 对 当前 类 加 锁 ， 进 入 同步 代码 前 
要 获得 当前 类 的 锁 。 


下 述 代 码 ， 将 synchronized 作 用 于 一 个 给 定 对 象 instance， 因 此 ， 
每 次 当 线 程 进入 被 synchronized 包 于 的 代码 段 ， 束 都 会 要 求 请 求 
instance 实 例 的 锁 。 如 果 当 前 有 其 他 线程 正 持 有 这 把 锁 ， 那 么 新 到 的 线 
程 就 必须 等 每 。 这 样 ， 就 保证 了 每 次 只 能 有 一 个 线程 执行 it+ 操 作 。 


public class AccountingSync implements Runnable{ 
static AccountingSync instance=new AccountingSync(); 
static int i=0; 


@Override 


public void run() { 
for(int j=0; j]<10000000; j++){ 
synchronized( instance) { 


lar 


1 


t 
//main 国 数 参 见 本 市 第 一 段 代码 


当然 ， 上 述 代 码 也 可 以 写成 如 下 形式 ， 两 者 古 等 价 的 : 


01 public class AccountingSync2 implements Runnable{ 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 


static AccountingSync2 instance=new AccountingSync2(); 


static int i=0; 
public synchronized void increase(){ 
oars 


了 


@Override 
public void run() { 
for(int j=0;j<10000000; j++) { 


increase(); 


public static void main(String[] args) 


InterruptedException { 


14 
15 


Thread ti=new Thread(instance); 


Thread t2=new Thread(instance) ; 


throws 


16 ti.start();t2.start(); 


17 t1.join();t2.join(); 
18 System.out.println(i); 
19 } 

20 } 


上 述 代 码 中 ，synchronized 关 键 字 作用 于 一 个 实例 方法 。 这 就 是 说 
在 进入 increase() 方 法 前 ， 线 程 必 须 获 得 当前 对 象 实 例 的 锁 。 在 本 例 中 
瓯 是 instance 对 象 。 在 这 里 ， 我 不 大 其 烦 地 再 次 给 出 main 函 数 的 实现 ， 
是 希望 强调 第 14、15 行 代码 ， 世 就 是 Thread 的 创建 方式 。 这 里 使 用 
Runnable 接 口 创建 两 个 线程 ， 并 且 这 两 个 线程 都 指 问 同一 个 Runnable 
接口 实例 (instance 对 象 ，， 这 样 才 能 保证 两 个 线程 在 工作 上 时， 能 够 关 
注 到 同一 个 对 象 锁 上 去 ， 从 而 保证 线程 安全 。 


一 种 错误 的 同步 方式 如 下 : 


01 public class AccountingSyncBad implements Runnable{ 


02 static int i=0; 

03 public synchronized void increase(){ 
04 Fay 

05 } 

06 @Override 

07 public void run() { 

08 for(int j=0;j<10000000;j++){ 

09 increase(); 

10 } 

11 } 


12 public static void main(String[] args) throws 


InterruptedException { 


13 Thread ti=new Thread(new AccountingSyncBad()); 
14 Thread t2=new Thread(new AccountingSyncBad()); 
15 t1.start();t2.start(); 

16 t1.join();t2.join(); 

17 System.out.printin(i); 

18 } 

19 } 


上 述 代 码 就 犯 了 一 个 严重 的 错误 。 虽 然 在 第 3 行 的 increase(0) 方 法 
中 ， 申 明 这 是 一 个 同步 方法 。 但 很 不 入 的 是 ， 执 行 这 段 代码 的 两 个 线 
程 都 指向 了 不 同 的 Runnable 实 例 。 由 第 13、14 行 可 以 看 到 ， 这 两 个 线 
程 的 Runnable 实 例 并 不 是 同一 个 对 象 。 因此， 线程 tl 会 在 进入 同步 方 
法 前 加 锁 上 自己 的 Runnable 实 例 ， 而 线程 2 也 关注 于 自己 的 对 象 锁 。 换 
言 之 ， 这 两 个 线程 使 用 的 是 两 把 不 同 的 锁 。 因 此 ， 线 程 安 全 是 无 法 你 
证 的 。 


但 我 们 只 要 人 简单 地 修改 上 述 代 码 ， 束 能 使 其 正确 执行 。 那 就 是 使 
用 synchronized 的 第 三 种 用 法 ， 将 其 作用 于 静态 方法 。 将 increase() 方 法 
修改 如 下 : 


public static synchronized void increase(){ 


i++; 


这 样 ， 即 使 两 个 线程 指向 不 同 的 Runnable 对 象 ， 但 由 于 方法 块 需 
要 请 求 的 是 当前 类 的 锁 ， 而 非 当 前 实例 ， 因 此 ， 线 程 间 还 是 可 以 正确 
同步 。 


除了 用 于 线程 同步 、 确 保 线程 安全 外 ，synchronized 还 可 以 保证 线 
程 间 的 可 见 性 和 有 序 性 。 从 可 见 性 的 角度 上 讲 ，synchronized 可 以 完全 
替代 volatile 的 功能 ， 只 是 使 用 上 没有 那么 方便 。 残 有 序 性 而 言 ， 由 于 
synchronized 限 制 每 次 只 有 一 个 线程 可 以 访问 同步 块 ， 因 此 ， 无 论 同步 
块 内 的 代码 如 何 被 乱 序 执行 ， 只 要 保证 串 行 语义 一 致 ， 那 么 执行 结果 
总 是 一 样 的 。 而 其 他 访问 线程 ， 又 必须 在 获得 锁 后 方 能 进入 代码 块 读 
取 数 据 ， 因 此 ， 它 们 看 到 的 最 终结 果 并 不 取决 于 代码 的 执行 过 程 ， 从 
而 有 序 性 问题 自然 得 到 了 解决 (换言之 ， 被 synchronized 限 制 的 多 个 线 
程 是 串 行 执行 的 ) 。 


2.8 程序 中 的 幽灵 : 隐藏 的 各 误 


作为 一 名 软件 开发 人 员 ， 修 复 程序 BUG 应 该 说 是 基本 的 日 常 工作 
之 一 。 作 为 Java 程 序 员 ， 也 许 你 经 常会 被 抛 出 的 一 大 堆 的 异 间 堆栈 所 
困扰 ， 因 为 这 可 能 预示 着 你 又 有 工作 可 做 了 。 但 我 这 里 想 说 的 是 ， 如 
果 程 序 出 错 ， 你 看 到 了 异常 堆栈 ， 那 你 应 该 感到 格外 的 高 兴 ， 因 为 这 
也 意味 着 你 极 有 可 能 可 以 在 两 分 钟 内 修复 这 个 问题 (当然 ， 并 不 是 所 
有 的 异常 都 是 错误 ) 。 最 可 怕 的 情况 是 ， 系统 没有 任何 异常 表现 ， 没 
有 日 志 ， 也 没有 堆栈 ， 但 是 却 给 出 了 一 个 错误 的 执行 结果 ， 这 种 情况 
下 ， 才 真 会 让 你 抓 狂 。 


2.8.1 无 提示 的 错误 案例 


我 在 这 里 想 给 出 一 个 系统 运行 错误 ， 却 没有 任何 提示 的 案例 。 让 
大 家 体会 一 下 这 种 情况 的 可 怕 之 处 。 我 相信 ， 在 任何 一 个 业务 系统 
中 ， 求 平均 值 ， 应 该 是 一 种 极其 常见 的 操作 。 这 里 吏 以 求 两 个 整数 的 
平均 值 为 例 。 请 看 下 面 代码 : 


int vi=1073741827; 
int v2=1431655768; 
System.out.printin("vi="+v1); 
System.out.printin("v2="+v2); 
int ave=(vitv2)/2; 


System.out.printin("ave="+ave); 


上 述 代 码 中 ， 加 粗 部 分 试图 计算 v1 和 v2 的 均值 。 乍 看 之 下 ， 没 有 
什么 问题 。 目 测 vi1 和 v2 的 当前 值 ， 售 计 两 者 的 平均 值 大 约 在 12 亿 左 
右 。 但 如 果 你 执行 代码 ， 却 会 得 到 以 下 输出 : 


v1=1073741827 
V2=1431655768 
ave=-894784850 


乍 看 之 下 ， 你 一 定 会 觉得 非常 吃惊 ， 为 什么 均值 竟然 反而 是 一 个 
负数 。 但 只 要 你 有 一 点 俩 发 精神 ， 束 会 马上 有 所 觉悟 。 这 是 一 个 典型 
的 溢出 问题 ! 显然 ，v1+v2 的 结果 就 已 经 导致 了 int 的 洪 出 。 


把 这 个 问题 单独 拿 出 来 研究 ， 也 许 你 不 会 有 特别 的 感触 ， 但 是 ， 
一 旦 这 个 问题 发 生 在 一 个 复杂 系统 的 内 部 。 由 于 复业 的 业务 逻辑 ， 很 
可 能 掩盖 这 个 看 起 来 微不足道 的 问题 ， 再 加 上 程序 目 始 至 终 没 有 任何 
日 志 或 异 第 ， 表 加 上 你 运气 不 是 太 好 的 话 ， 这 类 问题 不 让 你 耗 上 几 个 
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够 得 到 一 个 异常 或 者 相关 的 日 志 。 但 是 ， 非 常 不 六 的 是 ， 错 误 地 使 用 
并 行 ， 会 非常 容易 产生 这 类 问题 。 它 们 难 疯 路 影 ， 束 如 同 幽 灵 一 般 。 


2.8.2 ”并 发 下 的 ArrayList 


我 们 都 知道 ，ArrayList 是 一 个 线程 不 安全 的 容器 。 如 果 在 多 线程 
中 使 用 ArrayList， 可 能 会 导致 程序 出 错 。 那 究竟 可 能 引起 哪些 问题 
We? 试看 下 面 的 代码 : 


public class ArrayListMultiThread { 
static ArrayList<Integer> al = new ArrayList<Integer > 
(10); 
public static class AddThread implements Runnable { 
@Override 
public void run() { 
for (int i = 0; i < 1000000; I++) { 
al.add(i); 


public static void main(String[] args) throws 
InterruptedException { 
Thread ti=new Thread(new AddThread()); 
Thread t2=new Thread(new AddThread()); 
ti.start(); 
t2.start(); 
t1.join();t2.join(); 


System.out.println(al.size()); 


=z 


上 述 代 码 中 ，tL 和 t2 两 个 线程 同时 向 一 个 ArrayList 容 器 中 添加 容 
俩 。 他 们 各 添加 1000000 个 元 素 ， 因 此 我 们 期 望 最 后 可 以 有 2000000 个 
元 素 在 ArrayList 中 。 但 如 果 你 执行 这 段 代 码 ， 你 可 能 会 得 到 三 种 结 
果 o 


第 一 ， 程 序 正 常 结 束 ，ArrayList 的 最 终 大 小 确实 2000000。 这 说 明 
即使 并 行程 序 有 问题 ， 也 未 必 会 每 次 都 表现 出 来 。 


B, BPW: 


Exception in thread "Thread-0" 
java.lang.ArrayIndexOutOfBoundsException: 22 

at java.util.ArrayList.add(ArrayList.java:441) 

at geym.conc.ch2.notsafe.ArrayListMultiThread$AddThread.run 
(ArrayListMultiThread.java:12) 

at java.lang.Thread.run(Thread. java: 724) 
1000015 


这 是 因为 ArrayList 在 扩容 过 程 中 ， 内 部 一 致 性 被 破坏 ， 但 由 于 没 
有 锁 的 保护 ， 另 外 一 个 线程 访问 到 了 不 一 致 的 内 部 状态 ， 导 致 出 现 越 
界 问题 。 


第 三 ， 出 现 了 一 个 非常 隐蔽 的 错误 ， 比 如 打印 如 下 值 作为 
ArrayList 的 大 小 \: 


1793758 


显然 ， 这 是 由 于 多 线程 访问 冲突 ， 使 得 保存 容 右 大 小 的 变量 被 多 
线程 不 正常 的 访问 ， 同 时 两 个 线程 也 同时 对 ArrayList 中 的 同一 个 位 置 
进行 赋值 导致 的 。 如 果 出 现 这 种 问题 ， 那 么 很 不 他 ， 你 殉 得 到 了 一 个 
没有 错误 提示 的 错误 。 并 且 ， 他 们 未 必 是 可 以 复 现 的 。 


注意 : 改进 的 方法 很 简单 ， 使 用 线程 安全 的 Vector 代替 ArrayList 即 
可 。 


2.8.3 ”并 发 下 诡异 的 HashMap 


HashMap 同 样 不 是 线程 安全 的 。 当 你 使 用 多 线程 访问 HashMap 
时 ， 也 可 能 会 遇 到 意 想 不 到 的 错误 。 不 过 和 ArmayList 不 同 ，HashMap 
的 问题 似乎 更 加 诡异 。 


public class HashMapMultiThread { 


static Map<String,String> map = new HashMap<String, String 


>()7 


public static class AddThread implements Runnable { 
int start=0; 
public AddThread(int start){ 
this.start=start; 
} 
@Override 
public void run() { 
for (int i = start; i < 100000; i+=2) { 
map.put(Integer.toString(i), 
Integer.toBinaryString(1)); 
} 


public static void main(String[] args) throws 


InterruptedException { 
Thread ti=new Thread(new 
HashMapMultiThread.AddThread(0) ); 
Thread t2=new Thread (new 
HashMapMultiThread.AddThread(1)); 
ti.start(); 
t2.start(); 
t1.join();t2.join(); 


System.out.println(map.size()); 


上 述 代码 使 用 1 和 t2 两 个 线程 同时 对 HashMap 进 行 putO0 操 作 。 如 果 
一 切 正常 ， 我 们 期 望 得 到 的 map.size() 就 是 100000。 但 实际 上 ， 你 可 能 
会 得 到 以 下 三 种 情况 (注意 ， 这 里 使 用 JDK 7 进行 试验 ) : 


第 一 ， 程 序 正常 结束 ， 并 且 结果 也 是 符合 预期 的 。HashMap 的 大 
小 为 100000。 


第 二 ， 程 序 正 常 结束 ， 但 结果 不 符合 预期 ， 而 是 一 个 小 于 100000 
的 数字 ， 比 如 98868。 


第 三 ， 程 序 永 远 无 法 结束 。 

对 于 前 两 种 可 能 ， 和 ArrayList 的 情况 非常 类 似 ， 因 此 ， 也 不 必 过 
多 解释 。 而 对 于 第 三 种 情况 ， 如 果 十 第 一 次 看 到 ， 我 想 大 家 一 定 会 沉 
得 特别 惊讶 ， 因 为 看 似 非常 正常 的 程序 ， 怎 么 可 能 惑 结束 不 了 呢 ? 


TER: 请 读者 庶 慎 尝试 以 上 代码 ， 由 于 这 段 代码 很 可 能 占用 两 个 
CPU 核 ， 并 使 它们 的 CPU 占 有 率 达 到 100%。 如 果 CPU 性 能 较 弱 ， 
可 能 导致 死机 。 请 先 保 存 资 料 ， 再 进行 尝试 。 


打开 任务 管理 右 ， 你 们 会 发 现 ， 这 上段 代码 占用 了 极 蜗 的 CPU， 最 
有 可 能 的 表示 是 占用 了 两 个 CPU 核 ， 并 使 得 这 两 个 核 的 CPU 使 用 率 达 
到 1009%。 这 非常 类 似 死 循环 的 情况 。 


使 用 jstack 工 具 显 示 程 序 的 线程 信息 ， 如 下 所 示 。 其 中 jps 可 以 显示 
当前 系统 中 所 有 的 Java 进 程 。 而 jstack 可 以 打印 给 定 Java 进 程 的 内 部 线 
程 及 其 堆栈 。 


C:\Users\geym >jps 
14240 HashMapMultiThread 
1192 Jps 


C:\Users\geym >jstack 14240 
我 们 会 很 容易 找到 我 们 的 tL、t2 和 main 线 程 : 


"Thread-1" prio=6 tid=0x00bb2800 nid=0x16e0 runnable 
[0x04baf000] 
java.lang.Thread.State: RUNNABLE 
at java.util.HashMap.put(HashMap.java:498) 
at 
geym.conc.ch2.notsafe.HashMapMultiThread$AddThread.run 
(HashMapMultiThread. java: 26) 


at java.lang.Thread.run(Thread. java: 724) 


"Thread-0" prio=6 tid=0x00bb0000 nid=0x1668 runnable 
[0x04d7f000] 
java.lang.Thread.State: RUNNABLE 
at java.util.HashMap.put(HashMap.java:498) 
at 
geym.conc.ch2.notsafe.HashMapMultiThread$AddThread.run 
(HashMapMultiThread. java: 26) 
at java. lang. Thread.run(Thread.java:724) 
"main" prio=6  tid=0x00c0cc00 nid=0x1i6ec in Object.wait() 
[0x0102f000] 
java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
- waiting on <0x24930280> (a java.lang.Thread) 
at java.lang. Thread. join(Thread. java:1260) 
- locked <0x24930280> (a java.lang. Thread) 
at java.lang. Thread. join(Thread. java:1334) 
at 
geym.conc.ch2.notsafe.HashMapMultiThread.main(HashMapMultiThrea 


d. java:36) 


可 以 看 到 ， 主 线程 main 正 处 于 等 竺 状态， 并且 这 个 等 竺 是 由 于 
join0 方 法 引起 的 ， 符 合 我 们 的 预期 。 而 tL 和 也 两 个 线程 都 处 于 
Runnable 状 态 ， 并 且 当 前 执行 语句 为 HashMap.put() 方 法 。 查 看 put() 方 
法 的 第 498 行 代码 ， 如 下 所 示 : 


498 for (Entry<K,V> e = table[i]; e != null; e = e.next) { 
499 Object k; 


500 if (e.hash == hash && ((k = e.key) == key || 


key.equals(k))) { 

501 V oldValue = e.value; 
502 e.value = value; 

503 e.recordAccess(this); 
504 return oldValue; 

505 } 

506 } 


可 以 看 到 ， 当 前 这 两 个 线程 正在 过 历 HashMap 的 内 部 数据 。 当 前 
所 处 循环 乍 看 之 下 是 一 个 迭代 遍历 ， 就 如 同 涡 历 一 个 链表 一 样 。 但 在 
此 时 此 刻 ， 由 于 多 线程 的 冲突 ， 这 个 链表 的 结构 已 经 遭 到 了 破坏 ， 链 
KRAT! 当 链 表 成 环 时 ， 上 壕 的 迭代 束 等 同 于 一 个 死 循环 ， 如 图 2.9 
所 示 ， 展 示 了 最 简单 的 一 种 环 状 结构 ，Key1 和 Key2 互 为 对 方 的 next 元 
素 。 此 时 ， 通 过 next3 引 用 遍历 ， 将 形成 死 循环 。 


i | ~ 


| | 
_ | 


Lem | | Rey 2 
RÝ = edie na 
Value' | Value2 


一 一 一 
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图 2-9 ”成 环 的 链表 


这 个 死 循环 的 问题 ， 如 果 一 旦 发 生 ， 着 实 可 以 让 你 郁闷 一 把 。 本 
草 的 参考 资料 中 也 给 出 了 一 个 真实 的 案例 。 但 这 个 死 循环 的 问题 在 
JDK 8 中 已 经 不 存在 了 。 由 于 JDK 8 对 HashMap 的 内 部 实现 了 做 了 大 规 


模 的 调整 ， 因 此 规避 了 这 个 问题 。 但 即使 这 样 ， 贸 然 在 多 线程 环境 下 
使 用 HashMap 依 然 会 导致 内 部 数据 不 一 人 怪 。 最 简单 的 解决 方案 就 是 使 
用 ConcurrentHashMap 代 赫 HashMap。 


2.8.4 ”初学 者 常见 问题 ， 错 误 的 加 锁 


在 进行 多 ee 加 锁 是 保证 线程 安全 的 重要 手段 之 一 。 但 
加 锁 也 必须 是 合理 的 ， 在 “线程 安全 的 概念 与 synchronized” 一 节 中 ， 我 
PRIA tT — PACT A IN AAA o 也 就 是 锁 的 不 正确 使 用 。 在 
KPF, REMA —A ERE ER TR © 


ME, BARI eB PT Bas, PT a E PAA] 
访问 。 为 了 确 你 数据 正确 性 ， 我 们 目 然 会 需要 对 计数 器 加 锁 ， 因 此 ， 
mA T A PRI: 


01 public class BadLockOnInteger implements Runnable{ 


02 public static Integer i=0; 

03 static BadLockOnInteger instance=new BadLockOnInteger(); 
04 @Override 

05 public void run() { 

06 for(int j=0;j<10000000;j++){ 

07 synchronized(i){ 

08 工 十 十， 

09 } 

10 } 

11 } 


12 


13 public static void main(String[] args) throws 


InterruptedException { 


14 Thread ti=new Thread(instance) ; 
15 Thread t2=new Thread(instance) ; 
16 t1.start();t2.start(); 

17 t1.join();t2.join(); 

18 System.out.println(i); 

19 } 

20 } 


上 述 代 码 的 第 7~-9 行 ， 为 了 保证 计数 器 i 的 正确 性 ， 每 次 对 i 自 增 
前 ， 都 先 获 得 i 的 锁 ， 以 此 保证 ij 是 线程 安全 的 。 从 逻辑 上 看 ， 这 似乎 
并 没有 什么 不 对 ， 所 以 ， 我 们 或 满 怀 信心 地 尝试 运 行 我 们 的 代码 。 如 
果 一 切 正常 ， 这 段 代 码 应 该 返回 20000000 〈 每 个 线程 各 累加 10000000 
次 ) 


但 结果 却 让 我 们 惊 呆 了 ， 我 得 到 了 一 个 比 20000000 小 很 多 的 数 
字 ， 比 如 15992526。 这 说 明 什 么 问题 呢 ? 一 定 是 这 段 程序 并 没有 真正 
做 到 线程 安全 ! 但 把 锁 加 在 变量 i 上 又 有 什么 问题 呢 ? 似乎 加 锁 的 逻辑 
也 是 无 懈 可 击 的 。 


要 解释 这 个 问题 ， 得 从 Integer 说 起 。 在 Java 中 ，Integer 属 于 不 变 对 
象 。 也 就 是 对 象 一 旦 被 创建 ， 就 不 可 能 被 修改 。 也 就 是 说 ， 如 果 你 有 
一 个 Integer 代 表 1， 那 么 它 就 永远 表示 1， 你 不 可 能 修改 Integer 的 值 ， 
使 它 为 2。 那 如 果 你 需要 2 怎么 办 呢 ? 也 很 简单 ， 新 建 一 个 Integer， 并 
让 它 表 示 2 即 可 。 


如 果 我 们 使 用 javap 反 编译 这 段 代 码 的 run() 方 法 ， 我 们 可 以 看 到 : 


0 iconst_0 

1 istore_1 

2 goto 36 

5i getstatic #20; //Field i:Ljava/lang/Integer; 
8 dup 

9 astore_2 

10: monitorenter 

11: getstatic #20; //Field i:Ljava/lang/Integer; 


14: invokevirtual #32; //Method java/lang/Integer.intValue: 


17: iconst_1 

18: iadd 

19: invokestatic #14; //Method java/lang/Integer.valueOf: 
(I)Ljava/lang/Integer; 

22: putstatic #20; //Field i:Ljava/lang/Integer; 

25: aload_2 


26: monitorexit 


fER19~ 2247 (对 字 节 码 来 说 ， 这 是 偏 移 量 ， 这 里 简称 为 行 ) ， 
实际 上 使 用 了 ItegervalueOfO 方 法 新 建 了 一 个 新 的 Integer 对 象 ， 并 将 
它 赋值 给 变量 i。 也 就 是 说 ，i++ 在 真实 执行 时 变 成 了 : 


i=Integer.valueOf(i.intValue()+1); 
进一步 查看 IntegervalueOfO ， 我 们 可 以 看 到 : 


public static Integer valueOf(int i) { 


assert IntegerCache.high >= 127; 


if (1 >= IntegerCache.low && 1 <= IntegerCache.high) 
return IntegerCache.cache[i + (-IntegerCache.low) ]; 


return new Integer(i); 


IntegervalueOfO 实 际 上 是 一 个 工 广 方法， 它 会 倾 回 于 返回 一 个 代 
表 指 定数 值 的 Integer 实 例 。 因 此 ，i++ 的 本 质 是 ， 创 建 一 个 新 的 Integer 
对 象 ， 并 将 它 的 引用 赋值 给 i。 


如 此 一 来 ， 我 们 就 可 以 明白 问题 所 在 了 ， 由 于 在 多 个 线程 间 ， 并 
不 一 定 能 够 看 到 同一 个 i 对 象 (因为 | 对象 一 直 在 变 ) ， 因 此 ， 两 个 线 
程 每 次 加 锁 可 能 都 加 在 了 不 同 的 对 象 实例 上 ， 从 而 导致 对 临界 区 代码 
控制 出 现 问题 。 


修正 这 个 问题 也 很 容易 ， 只 要 将 
synchronized(i){ 


BR: 


synchronized(instance) { 


BURY ° 
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第 3 章 JDK 并 发 包 


为 了 更 好 地 文 持 并 发 程序 ，JDK 内 部 提供 了 大 量 实用 的 API 和 框 
o 在 本 章 中 ， 将 主要 介绍 这 些 JDK 内 部 的 功能 ， 其 主要 分 为 三 大 部 


本 


首先 ， 将 介绍 有 关 同 步 控制 的 工具 ， 之 前 介绍 的 synchronized 关 键 
字 束 是 一 种 同步 控制 手段 ， 在 这 里 ， 我 们 将 看 到 更 加 丰富 多 彩 的 多 线 
程控 制 方法 。 


其 次 ， 将 详细 介绍 JDK 中 对 线程 池 的 文 持 ， 使 用 线程 池 ， 将 能 很 
大 程度 上 提高 线程 调度 的 性 能 。 


， 我 将 向 大 家 介绍 JDK 的 一 些 并 发 容器 ， 这 些 容 器 专 为 并 行 
a 安全 、 稳定 的 实用 工具 。 


3.1 多 线程 的 团队 协作 :同步 控制 


同步 控制 是 并 发 程序 必 不 可 少 的 重要 手段 。 之 前 介绍 的 
synchronized 关 键 字 丈 是 一 种 最 简单 的 控制 方法 。 它 决定 了 一 个 线程 是 
否 可 以 访问 临界 区 资源 。 同 时 ，Object.wait0 和 Objectnotify0) 方 法 起 到 
了 线程 等 待 和 通知 的 作用 。 这 些 工 具 对 于 实现 复杂 的 多 线程 协作 起 到 
了 重要 的 作用 。 在 本 和 中 ， 我 们 首先 将 介绍 synchronized 、 
Object.wait0 和 Objectnotify0) 方 法 的 替代 品 〈 或 者 说 是 增强 版 ) — E 
入 锁 。 


a synchronized) sey Fe: BA 
J. 


EADH A EE (synchronized fF ° ÆJDK 5.0 的 早期 版 本 
中 ， 重 入 锁 的 性 能 远 远 好 于 synchronized， 但 从 JDK 6.0 开 始 ，JDK 在 
synchronized 上 做 了 大 量 的 优化 ， 使 得 两 者 的 性 能 差距 并 不 大 。 


重 入 锁 使 用 java.util.concurrent.locks.ReentrantLock 类 来 实现 。 下 面 
是 一 段 最 简单 的 重 入 锁 使 用 案例 : 


01 public class ReenterLock implements Runnable{ 


02 public static ReentrantLock lock=new ReentrantLock(); 
03 public static int i=0; 
04 @Override 


05 public void run() { 


06 for(int j=0;j<10000000;j++){ 


07 lock.lock(); 

08 try{ 

09 dt, 

10 }finally{ 

11 lock.unlock(); 

12 } 

13 } 

14 } 

L5 public static void main(String[] args) throws 


InterruptedException { 


16 ReenterLock tl=new ReenterLock(); 
17 Thread ti=new Thread(tl); 

18 Thread t2=new Thread(tl); 

19 ti.start();t2.start(); 

20 t1.join();t2.join(); 

21 System.out.println(i); 

22 } 

23 } 


上 述 代 码 第 7 全 12 行 ， 使 用 重 入 锁 保 护 I 临 界 区 资源 i， 确 保 多 线程 

对 i 操 作 的 安全 性 。 从 这 段 代 码 可 以 看 到 ， 与 synchronized 相 比 ， 重 入 

锁 有 着 显示 的 操作 过 程 。 开 发 人 员 必 须 手 动 指定 何 时 加 锁 ， 何 时 释放 

锁 。 也 正 因 为 这 样 ， 重 入 锁 对 逻辑 控制 的 灵活 性 要 远 远 好 于 

synchronized。 但 值得 注意 的 是 ， 在 退出 临界 区 时 ， 必 须 记 得 释放 锁 
〈 代 码 第 11 行 ) ， 否 则 ， 其 他 线程 就 没有 机 会 再 访问 临界 区 了 。 


有 些 同学 可 能 会 对 重 入 锁 的 名 字 感 到 奇怪 。 锁 就 叫 锁 喘 ， 为 什么 
要 加 上 “ 重 入 ”两 个 字 呢 ? 从 类 的 命名 上 看 ，Re- Entrant-Lock 翻 译 成 重 
入 锁 也 是 非常 贴切 的 。 之 所 以 这 么 叫 ， 那 是 因为 这 种 锁 是 可 以 反复 进 
入 的 。 当 然 ， 这 里 的 反复 仅仅 局 限于 一 个 线程 。 上 述 代 码 的 第 7 一 12 
行 ， 可 以 写成 下 面 的 形式 : 


lock.lock(); 

lock.lock(); 

try{ 
ie 

}finally{ 
lock.unlock(); 
lock.unlock(); 


在 这 种 情况 下 ， 一 个 线程 连续 两 次 获得 同一 把 锁 。 这 和 是 允 许 的 ! 

如 果 不 允 许 这 么 操作 ， 那 么 同一 个 线程 在 第 2 次 获得 锁 时 ， 将 会 和 上 自己 
产生 和 死 锁 。 程 序 束 会 * 卡 死 " 在 第 2 次 申请 锁 的 过 程 中 。 但 需要 注意 的 
是 ， 如 果 同 一 个 线程 多 次 获得 锁 ， 那 么 在 释放 锁 的 时 候 ， 也 必须 释放 
相同 次 数 。 如 采 释 放 锁 的 次 数 多 ， 那 么 会 得 到 一 个 
java.lang.IlegalMonitorStateException 异 常 ， 反 之 ， 如 果 释 放 锁 的 次 数 
少 了 ， 那 么 相当 于 线程 还 持 有 这 个 锁 ， 因 此 ， 其 他 线程 也 无 法 进入 临 
界 区 。 


除了 使 用 上 的 灵活 性 外 ， 重 入 锁 还 提供 了 一 些 高 级 功能 。 比 如 ， 
重 入 锁 可 以 提供 中 断 处 理 的 能 


。 中 断 响应 


对 于 synchronized 来 说， 如 果 一 个 线程 在 等 待 锁 ， 那 么 结果 只 有 两 
种 情况 ， 要 么 它 获得 这 把 锁 继 续 执 行 ， 要 么 它 束 保持 等 待 。 而 使 用 重 
入 锁 ， 则 提供 另外 一 种 可 能 ， 那 就 是 线程 可 以 被 中 断 。 也 就 是 在 等 得 
锁 的 过 程 中 ， 程 序 可 以 根据 需要 取消 对 锁 的 请 求 。 有 些 时 候 ， 这 么 做 
是 非常 有 必要 有 的。 比如， 如 果 你 和 朋友 约 好 一 起 去 打球 ， 如 果 你 等 了 
半 小 时 ， 朋 友 还 没有 a 到， 突然 授 到 一 个 电话 ， 说 由 于 突 发 情况 ， 不 能 
如 约 了 。 那 么 你 一 定 就 扫兴 地 打道 回 全 了。 中 断 正 式 提 供 了 一 套 类 似 
的 机 制 。 如 果 一 个 线程 正在 等 待 锁 ， 那 么 它 依然 可 以 收 到 一 个 通知 ， 
被 告知 无 须 再 等 待 ， 可 以 停止 工作 了 。 这 种 情况 对 于 处 理 死 锁 是 有 一 
定 帮助 的 。 


下 面 的 代码 产生 了 一 个 死 锁 ， 但 得 花 于 锁 中 断 ， 我 们 可 以 很 轻易 
地 解决 这 个 死 锁 。 


01 public class IntLock implements Runnable { 


02 public static ReentrantLock lock1 = new ReentrantLock(); 
03 public static ReentrantLock lock2 = new ReentrantLock(); 
04 int lock; 

05 jes 

06 * 控制 加 锁 顺 序 ， 方 便 构 造 死 锁 

07 * @param lock 

08 “y 

09 public IntLock(int lock) { 

10 this.lock = lock; 

11 } 

12 


13 @Override 


14 
15 
16 
i 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 


System.out.println(Thread.currentThread().getId()+" : 7HR H 


38 
39 


public void run() { 
try { 
if (lock == 1) { 
lock1.lockInterruptibly(); 
try{ 

Thread.sleep(500); 
}catch(InterruptedException e){} 
lock2.lockInterruptibly(); 

} else { 
lock2.lockInterruptibly(); 
try{ 

Thread.sleep(500); 
}catch(InterruptedException e){} 
lock1.lockInterruptibly(); 


} catch (InterruptedException e) { 
e.printStackTrace(); 
} finally { 
if (lock1.isHeldByCurrentThread()) 
lock1.unlock(); 
if (lock2.isHeldByCurrentThread()) 
lock2.unlock(); 


t 


i"); 


40 
41 public static void main(String[] args) throws 


InterruptedException { 


42 IntLock ri = new IntLock(1); 
43 IntLock r2 = new IntLock(2); 
44 Thread ti = new Thread(r1); 
45 Thread t2 = new Thread(r2); 
46 ti.start();t2.start(); 

47 Thread.sleep(1000); 

48 // 中 断 其 中 一 个 线程 

49 t2.interrupt(); 

50 } 

51 } 


线程 tL ALA Sa, 156 4 H lock1 , alt ie ae 
lock2， 再 请 求 lock1。 因 此 ， 很 容易 形成 tL 和 t2 之 间 的 相互 等 待 。 在 这 
里 ， 对 锁 的 请 求 ， 统 一 使 用 lockInterruptibly() 方 法 。 | 
呆 进 行 啊 应 的 锁 申 请 动作 ， 即 在 等 待 锁 的 过 程 中 ， 可 以 啊 应 中 断 。 


在 代码 第 47 行 ， 主 线程 main 处 于 休眠 ， 此 时 ， 这 两 个 线程 处 于 死 
MRE, EIT ， 由 于 了 2 线程 被 中 断 ， 故 t2 会 放弃 对 lock1 的 
申请 ， 同 时 释放 已 获得 lock2 o 这 个 操作 导致 {1 线程 可 以 顺利 得 到 ]ock2 
而 继续 执行 下 去 。 


执行 上 述 代 码 ， 将 输出 : 


java.lang.InterruptedException 


at java.util.concurrent.locks.AbstractQueuedSynchronizer. 


doAcquireInterruptibly(AbstractQueuedSynchronizer.java:898) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer. 
acquireInterruptibly(AbstractQueuedSynchronizer .java:1222) 
at 

java.util.concurrent.locks.ReentrantLock.lockInterruptibly 
(ReentrantLock.java:335) 

at geym.conc.ch3.synctrl.IntLock.run(IntLock. java: 31) 

at java.lang.Thread.run(Thread. java: 745) 
:线程 退出 
:线程 退出 


œo © 


可 以 看 到 ， 中 断后 ， 两 个 线程 双双 退出 。 但 真正 完成 工作 的 只 
t1。 而 2 线程 则 放弃 其 任务 直接 人 退出， 释放 资源 。 


* 锁 申请 等 待 限 时 


除了 等 每 外 部 通知 之 外 ， 要 避免 死 锁 还 有 男 外 一 种 方法 ， 那 就 是 
限时 等 待 。 依 然 以 约 朋友 打球 为 例 ， 如 果 朋 友 迟 返 不 来 ， 又 无 法 联系 
到 他 。 那 么 ， 在 等 待 1 一 2 个 小 时 后 ， 我 想 大 部 分 人 都 会 扫兴 离 去 。 对 
线程 来 说 也 是 这 样 。 通 常 ， 我 们 无 法 判断 为 什么 一 个 线程 迟 迟 拿 不 到 
锁 。 也 许 是 因为 死 锁 了 ， 也 许 是 因为 产生 了 饥饿 。 但 如 果 给 定 一 个 等 
每 时 间 ， 让 线程 目 动 放弃 ， 那么 对 系统 来 说 是 有 意义 的 。 我 们 可 以 使 
用 tryLock0 方 法 进行 一 次 限时 的 等 待 。 


下 面 这 段 代 码 展示 了 限时 等 待 锁 的 使 用 。 


01 public class TimeLock implements Runnable{ 


02 public static ReentrantLock lock=new ReentrantLock()j; 


03 @Override 


04 public void run() { 

05 try { 

06 if(lock.tryLock(5, TimeUnit.SECONDS) ) { 

07 Thread.sleep(6000); 

08 telse{ 

09 System.out.println("get lock failed"); 

10 } 

11 } catch (InterruptedException e) { 

12 e.printStackTrace(); 

13 }finally{if(lock.isHeldByCurrentThread() ) 


lock.unlock();} 


14 } 

L5 public static void main(String[] args) { 
16 TimeLock tl=new TimeLock(); 

17 Thread ti=new Thread(tl); 

18 Thread t2=new Thread(tl); 

19 t1.start(); 

20 t2.start(); 

21 } 

22 } 


在 这 里 ，tryLock0 方 法 接收 两 个 参数 ， 一 个 表示 等 待 时 长， 另外 
一 个 表示 计时 单位 。 这 里 的 单位 设置 为 秒 ， 时 长 为 5， 表 示 线 程 在 这 个 
锁 请 求 中 ， 最 多 等 得 5 秒 。 如 果 超 过 5 秒 还 没有 得 到 锁 ， 就 会 返回 
false。 如 果 成 功 获得 锁 ， 则 返回 true。 


在 本 例 中 ， 由 于 占用 锁 的 线程 会 持 有 锁 长 达 6 秒 ， 故 另 一 个 线程 无 
法 在 5 秒 的 等 待 时 间 内 获得 锁 ， 因 此 ， 请 求 锁 会 失败 。 


ReentrantLock.tryLock() 方 法 也 可 以 不 带 参 数 直 接 运 行 。 在 这 种 情 
况 下 ， 当 前 线程 会 尝试 获 得 锁 ， 如 果 锁 并 未 被 其 他 线程 占用 ， 则 申请 
锁 会 成 功 ， 并 立即 返回 true。 如 果 锁 人 被 其 他 线程 占用 ， 则 当前 线程 不 
会 进行 等 每 ， 而 是 立即 返回 false。 这 种 模式 不 会 引起 线程 等 待 ， 因 此 
也 不 会 产生 死 锁 。 下 面 演 示 了 这 种 使 用 方式 : 


01 public class TryLock implements Runnable { 


02 public static ReentrantLock lock1 = new ReentrantLock(); 
03 public static ReentrantLock lock2 = new ReentrantLock()j; 
04 int lock; 

05 

06 public TryLock(int lock) { 

07 this.lock = lock; 

08 } 

09 

10 @Override 

11 public void run() { 

12 if (lock == 1) 4 

13 while (true) { 

14 if (locki.tryLock()) { 

15 try { 

16 try { 

17 Thread.sleep(500); 


18 } catch (InterruptedException e) { 


19 } 


20 if (lock2.tryLock()) { 
21 try { 
22 


System.out.printin(Thread.currentThread( ) 

23 .getId() + ":My Job 
done"); 

24 return; 

25 } finally { 

26 lock2.unlock(); 
27 } 

28 J 

29 } finally { 

30 lock1.unlock(); 

31 t 

32 } 

33 } 

34 } else { 

35 while (true) { 

36 if (lock2.tryLock()) { 

37 try { 

38 try { 

39 Thread.sleep(500); 
40 } catch (InterruptedException e) { 
41 } 

42 if (lock1.tryLock()) { 
43 try { 


44 
System.out.printin(Thread.currentThread( ) 

45 .getId() + ":My Job 
done"); 

46 return; 

47 } finally { 

48 lock1.unlock(); 

49 } 

50 i 

51 } finally { 

52 lock2.unlock(); 

53 t 

54 } 

55 } 

56 } 

57 } 

58 

59 public static void main(String[] args) throws 


InterruptedException { 


60 TryLock ri = new TryLock(1); 
61 TryLock r2 = new TryLock(2); 
62 Thread t1 = new Thread(rt1); 
63 Thread t2 = new Thread(r2); 
64 ti.start(); 

65 t2.start(); 

66 } 


上 述 代 码 中 ， 采 用 了 非常 容易 死 锐 的 加 锁 顺 序 。 也 就 是 先 让 t1 获 
得 lock1， 再 让 t2 获 得 lock2， 接 着 做 反 加 请求 ， 让 t 申 请 lock2 ，t2 申 请 
lock1。 在 一 般 情况 下 ， 这 会 导致 上 L 和 t2 相 互 等 待 ， 从 而 引起 死 锁 。 


但 是 使 用 tryLock0O) 后 ， 这 种 情况 就 大 大 改善 了 『。 由 于 线程 不 会 傻 
自 地 等 待 ， 而 是 不 停 地 尝试， 因此 ， 只 要 执行 足够 长 的 时 间 ， 线 程 忌 
是 会 得 到 所 有 需要 的 资源 ， 从 而 正常 执行 (这 里 以 线程 同时 获得 lock1 
和 1lock2 两 把 锁 ， 作 为 其 可 以 正常 执行 的 条 件 ) 。 在 同时 获得 lock1 和 
lock2 后 ， 线 程 束 打印 出 标志 着 任务 完成 的 信息 “My Job done”。 


执行 上 述 代 码 ， 等 待 一 会 儿 (由 于 线程 中 包含 休眠 500 上 毫秒 的 代 
码 ) 。 最 终 你 还 是 可 以 欣喜 地 看 到 程序 执行 完毕 ， 并 产生 如 下 输出 ， 
表示 两 个 线程 双双 正 稼 执行 。 


9:My Job done 
8:My Job done 


. 公平 锁 


在 大 多 数 情况 下 ， 锁 的 申请 都 是 非 公平 的 。 也 吏 是 说 ， 线 程 1 首 爷 
请 求 了 锁 A， 接 着 线程 2 也 请 求 了 锁 A。 那 么 当 锁 A 可 用 时 ， 是 线程 1 可 
以 获得 锁 还 是 线程 2 可 以 获得 锁 呢 ? 这 是 不 一 定 的 。 系 统 只 是 会 从 这 个 
锁 的 等 待 队列 中 随机 挑选 一 个 。 因 此 不 能 保证 其 公平 性 。 这 天 好 比 天 
票 不 排队 ， 大 家 部 乱 哄 哄 得 围 在 售票 窗口 前 ， 售 票 员 人 忙 得 焦头烂额 ， 
也 顾 不 及 谁 先 谁 后 ， 随 便 找 个 人 出 票 惑 完事 了 “。 而 公平 的 锁 ， 则 不 是 
这 样 ， 它 会 按照 时 间 的 先后 顺序 ， 保 证 完 到 首先 得 ， 后 到 者 后 得 。 公 
平 锁 的 一 大 特点 是 : 它 不 会 产生 饥饿 现象 。 只 要 你 排队 ， 最 终 还 是 可 
以 等 到 资源 的 。 如 果 我 们 使 用 synchronized 关 键 字 进行 锁 控 制 ， 那 么 产 


生 的 锁 欧 是 非 公平 的 。 而 重 入 锁 允 许 我 们 对 其 公平 性 进行 设置 。 它 有 
一 个 如 下 的 构造 画 数 : 


public ReentrantLock(boolean fair) 


当 参 数 fair 为 true 时 ， 表 示 锁 是 公平 的 。 公 平 锁 看 起 来 很 优美 ， 但 
征 要 实现 公平 锁 必 然 要 求 系统 维护 一 个 有 序 队 列 ， 因 此 公平 锁 的 实现 
成 本 比较 高 ， 性 能 相对 也 非常 低下 ， 因 此 ， 默 认 情 况 下 ， 锁 是 非 公平 
的 。 如 采 没 有 特别 的 需求 ， 也 不 需要 使 用 公平 锁 。 公 平 锁 和 非 公 平 锁 
在 线程 调度 表现 上 也 是 非常 不 一 样 的 。 下 面 的 代码 可 以 很 好 地 突出 公 
平 锁 的 特点 : 


01 public class FairLock implements Runnable { 
02 public static ReentrantLock fairLock = new 


ReentrantLock(true); 


03 

04 @Override 

05 public void run() { 

06 while(true) { 

07 try{ 

08 fairLock.lock(); 
09 


System.out.println(Thread.currentThread().getName()+" 获得 锁 " ) ; 


10 }finally{ 

11 fairLock.unlock(); 
12 } 

13 } 


14 } 


15 
16 public static void main(String[] args) throws 


InterruptedException { 


17 FairLock ri = new FairLock(); 

18 Thread ti=new Thread(ri, "Thread_ti"); 
19 Thread t2=new Thread(ri, "Thread_t2"); 
20 ti.start();t2.start(); 

21 } 

22 } 


上 述 代 码 第 2 行 ， 指 定 锁 是 公平 的 。 拉 着， 由 两 个 线程 t1 和 t2 分 别 
请 求 这 把 锁 ， 并 且 在 得 到 锁 后 ， 进 行 一 个 控制 台 的 输出 ， 表 示 目 己 得 
到 了 锁 。 在 公平 锁 的 情况 下 ， 得 到 输出 通常 如 下 所 示 : 


Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 


由 于 代码 会 产生 大 量 输出 ， 这 里 只 截取 部 分 进行 说 明 。 在 这 个 输 
出 中 ， 很 明显 可 以 看 到 ， 两 个 线程 基本 上 是 交替 获得 锁 的 ， 几 乎 不 会 
发 生 同 一 个 线程 连续 多 次 获得 锁 的 可 能 ， 从 而 公平 性 也 得 到 了 保证 。 


如 果 不 使 用 公平 锁 ， 那 么 情况 会 完全 不 一 样 ， 下 面 是 使 用 非 公 平 锁 时 
的 部 分 输出 : 

前 面 还 有 一 大 段 t1 连 续 获得 锁 的 输出 

Thread_t1 获得 锁 


Thread_t1 获得 锁 
Thread_t1 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
后 面 还 有 一 大 段 t2 连 续 获 得 锁 的 输出 


可 以 看 到 ， 根 据 系统 的 调度 ， 一 个 线程 会 倾 问 于 再 次 获取 已 经 持 
有 的 锁 ， 这 种 分 配方 式 是 高 效 的 ， 但 是 无 公平 性 可 言 。 


对 上 面 ReentrantLock 的 几 个 重要 方法 整理 如 下 。 


。 lock): 获得 锁 ， 如 果 锁 已 经 被 占用 ， 则 等 每 。 

e lockInterruptibly(): 获得 锁 ， 但 优先 啊 应 中 汤 。 

。 tryLock0: 和 芝 试 获得 锁 ， 如 果 成 功 ， 返 回 true， 失 败 返 回 false。 
该 方法 不 等 待 ， 立 即 返回 。 

。 tryLock(long time, TimeUnit unit): 在 给 定时 间 内 党 试 获得 锁 。 

。 unlock(): 释放 锁 。 


忠 重 入 锁 的 实现 来 看 ， 它 主要 集中 在 Java 层 面 。 在 重 入 锁 的 实现 
， 主 要 包含 二 个 要 素 : 


第 一 ， 是 原子 状态 。 原 子 状态 使 用 CAS 操 作 (在 第 4 章 进行 详细 讨 
论 ) 来 存储 当前 锁 的 状态 ， 判 断 锁 是 否 已 经 被 别 的 线程 持 有 。 


第 二 ， 是 等 待 队列 。 所 有 没有 请 求 到 锁 的 线程 ， 会 进入 等 竺 队列 
进行 等 待 。 竺 有 线程 释放 锁 后 ， 系 统 束 能 从 等 待 队列 中 唤醒 一 个 
线程 ， 继 续 工 作 。 


第 三 ， 是 阻塞 原 语 park() 和 unpark()， 用 来 挂 起 和 恢复 线程 。 没 有 


得 到 锁 的 线程 将 会 被 挂 起 。 有关 park0 和 unpark0O 的 详细 介绍 ， 可 
以 参考 3.1.7 线 程 阻 塞 工 具 类 : ~LockSupport ° 


BA AEE: Condition 条 


如 果 大 家 理解 了 Objectwait0 和 Objectnotify0) 方 法 的 话 ， 那 么 吏 能 


很 容易 地 理解 Condition 对 象 了 。 它 和 wait0 和 notify(0) 方 法 的 作用 是 大 致 
相同 的 。 但 是 wait0 和 notify0 方 法 是 和 synchronized 关 键 字 合作 使 用 
的 ， 而 Condtion 是 与 重 入 锁 相 关联 的 。 通 过 Lock 接 口 ( 重 入 锁 就 实现 
了 这 一 接口 ) 的 Condition newCondition() 方 法 可 以 生成 一 个 与 当前 重 
入 锁 绑 定 的 Condition 实 例 。 利 用 Condition 对 象 ， 我 们 就 可 以 让 线程 在 
合适 的 时 间 等 待 ， 或 者 在 某 一 个 特定 的 时 刻 得 到 通知 ， 继 续 执 行 。 


Condition 接 口 提供 的 基本 方法 如 下 : 


void await() throws InterruptedException; 


void awaitUninterruptibly(); 


long awaitNanos(long nanosTimeout) throws InterruptedException; 


boolean await(long time, TimeUnit unit ) throws 


InterruptedException; 


boolean awaitUntil(Date deadline) throws InterruptedException; 


void signal(); 


void signalAll(); 


以 上 方法 的 含义 如 下 : 


。 await() 方 法 会 使 当前 线程 等 待 ， 同 时 释放 当前 锁 ， 当 其 他 线程 
中 使 用 signal0 或 者 signalAl10 方 法 时 ， 线 程 会 重新 获得 锁 并 继续 
执行 。 或 者 当 线 程 被 中 断 时 ， 也 能 跳出 等 待 。 这 和 Object.wait0) 
方法 很 相似 。 

e awaitUninterruptibly() 方 法 与 await0 方 法 基本 相同 ， 但 是 它 并 不 
会 在 等 竺 过程 中 啊 应 中 断 。 

。 singal() 方 法 用 于 唤醒 一 个 在 等 每 中 的 线程 。 相 对 的 singalAll0 方 
法 会 唤醒 所 有 在 等 竺 中 的 线程 。 这 和 Obejct.notify0) 方 法 很 类 
似 。 


下 面 的 代码 简单 地 演示 了 Condition 的 功能 : 


01 public class ReenterLockCondition implements Runnablef{ 


02 
03 
04 
05 


public static ReentrantLock lock=new ReentrantLock(); 
public static Condition condition = lock.newCondition(); 
@Override 


public void run() { 


06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 


try { 
lock.lock(); 


condition.await(); 
System.out.printin("Thread is going on"); 
} catch (InterruptedException e) { 
e.printStackTrace(); 
}finally{ 
lock.unlock(); 


public static void main(String[] args) throws 


InterruptedException { 


17 
18 
19 
20 
21 
22 
23 


ReenterLockCondition tl=new ReenterLockCondition(); 
Thread ti=new Thread(tl); 

t1.start(); 

Thread.sleep(2000); 

// 通 知 线程 t1 继 续 执 行 

lock.lock(); 

condition.signal(); 


lock.unlock(); 


第 3 行 ， 通 过 lock 生 成 一 个 与 之 绑 定 的 Condition 对 象 。 代 码 第 


8 行 ， 要 求 线程 在 Condition 对 象 上 进行 等 待 。 代 码 第 23 行 ， 由 主线 程 
main 发 出 通知 ， 告 知 等 竺 在 Condition 上 的 线程 可 以 继续 执行 了 。 


和 Object.wait() 和 notify() 方 法 一 样 ， 当 线程 使 用 Condition.await() 
上 时， 要 求 线程 持 有 相关 的 重 入 锁 ， 在 Condition.await() 调 用 后 ， 这 个 线 
程 会 释放 这 把 锁 。 同 理 ， 在 Condition.signal() 方 法 调用 时 ， 也 要 求 线程 
先 获 得 相关 的 锁 。 在 signal0 方 法 调用 后 ， 系 统 会 从 当前 Condition 对 象 
的 等 待 队 列 中 ， 唤 醒 一 个 线程 。 一 旦 线程 被 唤醒 ， 它 会 重新 尝试 获得 
与 之 绑 定 的 重 入 锁 ， 一 旦 成 功 获 取 ， 束 可 以 继续 执行 了 。 因 此 ， Æ 
signal0 方 法 调用 之 后 ， 一 般 需 要 释放 相关 的 锁 ， 谦 让 给 被 唤醒 的 线 
程 ， 让 它 可 以 继续 执行 。 比 如 ， 在 本 例 中 ， 第 24 行 代码 残 释 放 了 重 入 
锁 ， 如 果 省 略 第 24 行 ,那么 ， 虽 然 已 经 唤醒 了 线程 (， 但 是 由 于 它 无 
法 重 狐 获得 锁 ， 因 而 也 就 无 法 真正 的 继续 执行 。 


在 JDK 内 部 ， 重 入 锁 和 Condition 对 象 被 广泛 地 使 用 ， 以 
ArrayBlockingQueue 为 例 (可 以 参阅 “3.3 JDK 并 发 容器 ”一 广 ) ， 它 的 
put0 方 法 实现 如 下 : 


// 在 ArrayBlockingQueue 中 的 一 些 定义 

private final ReentrantLock lock; 

private final Condition notEmpty; 

private final Condition notFull; 

lock = new ReentrantLock(fair); 

notEmpty = lock.newCondition(); // 生 成 一 个 与 1ock 绑 定 
的 Condition 


notFull = lock.newCondition(); 


//put( ) 方 法 的 实现 
public void put(E e) throws InterruptedException { 


if (e == null) throw new NullPointerException(); 


final E[] items = this.items; 


final ReentrantLock lock = this.lock; 


lock. lockInterruptibly(); // 对 put( ) 方 法 做 同步 
try { 
try { 
while (count == items.length) // 如 采 当 前 队列 已 满 
notFull.await(); // 等 待 队列 有 足够 的 至 
间 
} catch (InterruptedException ie) { 
notFull.signal(); 
throw ie; 
} 
insert(e); // 当 notFu11 被 通知 
时 ， 说 明 有 足够 空间 
} finally { 
lock.unlock(); 
} 
} 


private void insert(E x) { 

items[putIndex] = x; 

putIndex = inc(putIndex); 

++count; 

notEmpty.signal(); // 通 知 需要 take( ) 的 线 
程 ， 队 列 已 有 数据 
} 


同 理 ， 对 应 take() 方 法 实现 如 下 : 


public E take() throws InterruptedException { 


final ReentrantLock lock = this.lock; 


lock. lockInterruptibly(); // 对 take( ) 方 法 做 同步 
try { 
try { 
while (count == 0) // 如 果 队 列 为 空 
notEmpty.await(); // 则 消费 者 队列 要 等 待 
一 个 非 空 的 信号 


} catch (InterruptedException ie) { 
notEmpty.signal(); 
throw ie; 

} 

E x = extract(); 

return x; 

} finally { 
lock.unlock(); 


i 


private E extract() { 

final E[] items = this.items; 

E x = items[takeIndex]; 

items[takeIndex] = null; 

takeIndex = inc(takeIndex); 

--count; 

notFull.signal(); // 通 知 put( ) 线 程 队 列 
BAAS Al 


return x; 


Ww 


3.1.3 ”人 允许 多 个 线程 同时 访问 : 信号 
量 (Semaphore) 


信和 号 量 为 多 线程 协作 提供 了 更 为 强大 的 控制 方法 。 广 义 上 说 ， 信 
号 量 是 对 锁 的 扩展 。 无 论 是 内 部 锁 synchronized 还 是 重 入 锁 
ReentrantLock， 一 次 都 只 允许 一 个 线程 访问 一 个 资源 ， 而 信号 量 却 可 
以 指定 多 个 线程 ， 同 时 访问 某 一 个 资源 。 信 和 号 量 主 要 提供 了 以 下 构造 
EBM: 


public Semaphore(int permits) 


public Semaphore(int permits, boolean fair) // 第 二 个 参数 可 以 指 
定 是 否 公平 


在 构造 信号 量 对 象 时 ， 必 须要 指定 信号 量 的 准 入 数 ， 即 同时 能 
请 多 少 个 许可 。 当 每 个 线程 每 次 只 申请 一 个 许可 时 ， 这 束 相 当 于 指定 
了 同时 有 多 少 个 线程 可 以 访问 某 一 个 闹 源 。 信 与 量 的 主要 逻辑 方法 
F: 


public void acquire() 

public void acquireUninterruptibly() 

public boolean tryAcquire() 

public boolean tryAcquire(long timeout, TimeUnit unit) 


public void release() 


acquire(0) 方 法 尝试 获得 一 个 准 入 的 许可 。 寿 无 法 获得 ， 则 线程 会 
等 每 ， 直 到 有 线程 释放 一 个 许可 或 者 当前 线程 被 中 断 。 
acquireUninterruptibly0) 方 法 和 acquire() 方 法 类 似 ， 但 是 不 啊 应 中 断 。 
tryAcquire() 尝 试 获得 一 个 许可 ， 如 果 成 功 返 回 true， 失 败 则 返回 false， 
它 不 会 进行 等 待 ， 立 即 返 回 。release() 用 于 在 线程 访问 资源 结束 后 ， 释 
放 一 个 许可 ， 以 使 其 他 等 得 许可 的 线程 可 以 进行 资源 访问 。 


在 JDK 的 官方 Javadoc 中 ， 就 有 一 个 有 关 信 与 量 使 用 的 人 简单 实例 ， 
有 兴趣 的 读者 可 以 目 行 翻阅 ， 这 里 我 给 出 一 个 更 加 傻瓜 化 的 例子 : 


01 public class SemapDemo implements Runnable{ 


02 final Semaphore semp = new Semaphore(5); 
03 @Override 

04 public void run() { 

05 try { 

06 semp.acquire(); 

07 // 模 拟 耗 时 操作 

08 Thread.sleep(2000); 

09 


System.out.println(Thread.currentThread().getId()+":done!"); 


10 semp.release(); 

11 } catch (InterruptedException e) { 
12 e.printStackTrace(); 

13 } 

14 } 

iiS 


16 public static void main(String[] args) { 


17 ExecutorService exec = 


Executors.newFixedThreadPool (20); 


18 final SemapDemo demo=new SemapDemo(); 
19 for(int 1=0;1<20;i+t+){ 

20 exec. submit(demo) ; 

21 } 

22 } 

23) } 


上 述 代 码 中 ， 第 7~9 行 为 临界 区 管理 代码 ， 程 序 会 限制 执行 这 段 
代码 的 线程 数 。 这 里 在 第 2 行 ， 申 明了 一 个 包含 5 个 许可 的 信号 量 。 这 
瓯 意味 着 同时 可 以 有 5 个 线程 进入 代码 段 第 7~9 行 。 申 请 信和 号 量 使 用 
acquireO 探 作 ， 在 离开 时 ， 务 必 使 用 release0 释 放 信 号 量 (代码 第 10 
ÍT) 。 这 承 和 释放 锁 是 一 个 道理 。 如 果 不 季 发 生 了 信和 号 量 的 泄露 ( 申 
请 了 但 没有 释放 ) ， 那 么 可 以 进入 临界 区 的 线程 数量 就 会 越 来 越 少 ， 
直到 所 有 的 线程 均 不 可 访问 。 在 本 例 中 ， 同 时 开启 20 个 线程 。 观 察 这 
段 程 序 的 输出 ， 你 束 会 发 现 系 统 以 5 个 线程 一 组 为 单位 ， 依 次 输出 带 有 
线程 ID 的 提示 文本 。 


3.1.4 ReadWriteLockiz 3 #i 


ReadWriteLock 是 JDK5 中 提供 的 读 写 分 离 锁 。 读 写 分 离 锁 可 以 有 
效 地 帮助 减少 锁 苑 争 ， 以 提升 系统 性 能 。 用 锁 分 离 的 机 制 来 提升 性 能 
韭 常 容易 理解 ， 比 如 线程 A1、A2、A3 进 行 写 操作 ，B1、B2、B3 进 行 
读 操 作 ， 如 果 使 用 重 入 锁 或 者 内 部 锁 ， 则 理论 上 说 所 有 读 之 间 、 读 与 
写 之 间 、 写 和 写 之 间 都 是 串 行 操作 。 当 Bl 进行 读 取 时 ，B2、B3 则 需要 


等 待 锁 。 由 于 读 操作 并 不 对 数据 的 完整 性 造成 破坏 ， 这 种 等 待 显然 是 
不 合理 。 因 此 ， 读 写 锁 就 有 了 发 挥 功能 的 余地 。 


在 这 种 情况 下 ， 读 写 锁 允许 多 个 线程 同时 读 ， 使 得 B1、B2、B3 之 
间 真 正 并 行 。 但 是 ee a 写 写 操作 和 读 写 操作 间 依 然 
是 需要 相 互 等 待 和 持 有 锁 的 。 总 的 来 说 ， 读 写 锁 的 访问 约束 如 表 3. 所 
示 


43.1 读 写 锁 的 访问 约束 情况 


。 读 - 读 不 互 斥 ， 读 读 之 间 不 阻塞 。 
。 读 - 写 互 斥 ， 读 阻塞 写 ， 写 也 会 阻塞 读 。 


。 写 - 写 互 斥 ， 写 写 阻塞 。 


如 条 在 系统 中 ， 读 操作 次 数 远 远 大 于 写 操 作 ， 则 读 写 锁 束 可 以 发 
挥 最 大 的 功效 ， 提 升 系统 的 性 能 。 这 里 我 给 出 一 个 稍微 僵 张 点 的 案 
例 ， 来 说 明 读 写 锁 对 性 能 的 帮助 。 


01 public class ReadwriteLockDemo { 

02 private static Lock lock=new ReentrantLock(); 

03 private static ReentrantReadwriteLock readwriteLock=new 
ReentrantReadwriteLock(); 


04 private static Lock readLock = readWriteLock.readLock()j; 


05 private static Lock writeLock = 


readwriteLock.writeLock(); 


06 private int value; 
07 
08 public Object handleRead(Lock lock) throws 


InterruptedException{ 


09 try{ 

10 lock.lock(); // 模 拟 读 操作 

ni Thread. sleep(1000); // 读 操作 的 耗 时 越 多 ， 读 
写 锁 的 优势 就 越 明显 

12 return value; 

i es }finally{ 

14 lock.unlock(); 

15 } 

16 } 

17 

18 public void handlewrite(Lock lock,int index) throws 


InterruptedException{ 


19 try{ 

20 lock.lock(); // 模 拟 写 操作 
21 Thread.sleep(1000); 

22 value=index; 

23 }finally{ 

24 lock.unlock(); 

25 } 

26 } 


27 


28 public static void main(String[] args) { 
29 final ReadwriteLockDemo  demo=new 


ReadwriteLockDemo(); 


30 Runnable readRunnale=new Runnable() { 

31 @Override 

32 public void run() { 

33 try { 

34 demo .handleRead(readLock); 
58/7 demo.handleRead( lock); 

36 } catch (InterruptedException e) { 
37 e.printStackTrace(); 

38 } 

39 } 

40 jp 

41 Runnable writeRunnale=new Runnable() { 

42 @Override 

43 public void run() { 

44 try { 

45 demo. handlewrite(writeLock, new 


Random().nextiInt()); 
46 // demo. handlewrite(lock, new 


Random().nextInt()); 


47 } catch (InterruptedException e) { 
48 e.printStackTrace(); 

49 } 

50 } 


51 bp 


53 for(int i=0;i<18;i++){ 


54 new Thread(readRunnale).start(); 


57 for(int 1=18;1<20;i++){ 


58 new Thread(writeRunnale).start(); 


上 述 代 码 中 ， 第 11 行 和 第 21 行 分 别 模拟 了 一 个 非常 耗 时 的 操作 ， 
让 线程 耗 时 1 秒 钟 。 它 们 分 别 对 应 读 耗 时 和 写 耗 时 。 代 码 第 34 和 45 行 ， 
分 别 是 读 线程 和 写 线 程 。 在 这 里 ， 第 34 行 使 用 读 锁 ， 第 35 行 使 用 写 
锁 。 第 53 一 55 行 开局 18 个 读 线程 ， 第 57~ 僵 59 行 ， 开 局 两 个 写 线程 。 由 
于 这 里 使 用 了 读 写 分 离 ， 因 此 ， 读 线程 完全 并 行 ， 而 写 会 阻塞 读 ， 
此 ， 实 际 上 这 段 代码 运行 大 约 2 秒 多 怠 能 结束 〈 写 线程 之 间 是 实际 串 行 
的 ) 。 而 如 果 使 用 第 35 行 代替 第 34 行 ， 使 用 第 46 行 代替 第 45 行 执行 上 
述 代 码 ， 即 ， 使 用 普通 的 重 入 锁 代 替 读 写 锁 。 那 么 所 有 的 读 和 写 线 程 
之 间 都 必须 相互 等 待 ， 因 此 整个 程序 的 执行 时 间 将 长 达 20 余 秒 。 


3.1.5 {r FITZ: CountDownLatch 


CountDownLatch 是 一 个 非常 实用 的 多 线程 控制 工具 类 。“Count 
Down” 在 英文 中 意 为 倒 计 数 ，Latch 为 门 门 的 意思 。 如 果 翻 译 成 为 倒 计 
数 门 门 ， 我 想 大 家 都 会 觉得 不 知 所 云 吧 ! 因此 ， 这 里 简单 地 称 之 为 倒 


Waar ° XH, MANS Ge: 把 门 锁 起 来 ， 不 证 里 面 的 线程 跑 出 
来 。 因 此 ， 这 个 工具 通常 用 来 控制 线程 等 每 它 可 以 让 某 一 个 线程 等 
待 直 到 倒计时 结束 ， 再 开始 执行 。 


对 于 倒计时 右 ， 一 种 典型 的 场景 束 是 火箭 发 射 。 在 火箭 发 射 前 ， 
为 了 保证 万 无 一 失 ， 往 往 还 要 进行 各 项 设备 、 仪 右 的 检查 。 只 有 等 所 
有 的 检查 完毕 后 ， 引 警 才 能 点 火 。 这 种 场景 就 非常 适合 使 用 
CountDownLatch。 它 可 以 使 得 点 火线 程 等 等 所 有 检查 线程 全 部 完工 
后 ， 再 执行 。 


CountDownLatch 的 构造 画 数 接收 一 个 整数 作为 参数 ， 即 当前 这 个 
计数 器 的 计数 个 数 。 


public CountDownLatch(int count) 


下 面 这 个 简单 的 示例 ， 演 示 了 CountDownLatch 的 使 用 。 


01 public class CountDownLatchDemo implements Runnable { 


02 static final CountDownLatch end 三 new 
CountDownLatch(10); 
03 static Final CountDownLatchDemo demo=new 


CountDownLatchDemo(); 


04 @Override 

05 public void run() { 

06 try { 

07 // 模 拟 检查 任务 

08 Thread.sleep(new Random().nextInt(10)*1000); 


09 System.out.println("check complete"); 


10 end ,countDown( ) 


11 } catch (InterruptedException e) { 

12 e.printStackTrace(); 

13 } 

14 } 

i5 public static void main(String[] args) throws 


InterruptedException { 
16 ExecutorService exec = 


Executors.newFixedThreadPool(10); 


17 for(int 1=0;1<10;it+){ 

18 exec .submit (demo); 

19 } 

20 // 等 待 检 查 

21 end.await(); 

22 // BN AG 

23 System.out.println("Fire!"); 
24 exec.shutdown(); 

25 } 

26 } 


上 述 代 码 第 2 行 ， 生 成 一 个 CountDownLatch 实 例 。 计 数 数量 为 
10。 这 表示 需要 有 10 个 线程 完成 任务 ， 等 待 在 CountDownLatch 上 的 线 
程 才能 继续 执行 。 代 码 第 10 行 ， 使 用 了 CountDownLatch.countdown() 方 
法 ， 也 就 是 通知 CountDownLatch， 一 个 线程 已 经 完成 了 任务 ， 倒 计时 
右 可 以 减 1 啦 。 第 21 行 ， 使 用 CountDownLatch.await(0) 方 法 ， 要 求 主线 
程 等 待 所 有 10 个 检查 任务 全 部 完成 。 待 10 个 任务 全 部 完成 后 ， 主 线程 
才能 继续 执行 。 


上 述 和 案例 的 执行 逻辑 可 以 用 图 3.1 简 单 表 示 。 
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图 3.1 ”CountDownLatch 示 意图 


主线 程 在 CountDownLatch 上 等 待 ， 当 所 有 检查 任务 全 部 完成 后 ， 
主线 程 方 能 继续 执行 。 


3.1.6 ”循环 概 栏 : CyclicBarrier 


CyclicBarrier 是 男 外 一 种 多 线程 并 发 控制 实用 工具 。 和 
CountDownLatch 非 常 类 似 ， 它 也 可 以 实现 线程 间 的 计数 等 待 ， 但 它 的 
功能 比 CountDownLatch 更 加 复杂 且 强 大 。 


CyclicBarrier 可 以 理解 为 循环 栅栏 。 栅 栏 就 古 一 种 障碍 物 ， 比 如 ， 
通常 在 私人 宅 铸 的 周围 束 可 以 围 上 一 圈 栅 栏 ， 阻止 用 杂 人 等 入 内 。 这 
里 当然 束 是 用 来 阻止 线程 继续 执行 ， 要 求 线程 在 栅栏 处 等 每 。 前 面 
Cydlic 意 为 循环 ， 也 就 是 说 这 个 计数 器 可 以 反复 使 用 。 比 如 ， 假 设 我 
们 将 计数 占 设 置 为 10， 那 么 凑 齐 第 一 批 10 个 线程 后 ， 计 数 右 束 会 归 
零 ， 然 后 接着 凑 齐 下 一 批 10 个 线程 ， 这 束 是 循环 权 柱 内 在 的 合 义 。 


CyclicBarrier 的 使 用 场景 也 很 丰富 。 比 如 ， 司 令 下 达 命 令 ， 要 求 10 
个 士兵 一 起 去 完成 一 项 任务 。 这 时 ， 就 会 要 求 10 个 士兵 先 集合 报道 ， 
接着 ， 一 起 雄 趟 直 气 昂昂 地 去 执行 任务 。 当 10 个 士兵 把 目 己 手头 的 任 
务 都 执行 完成 了 ， 那 么 司令 才能 对 外 宣布 ， 任 务 完 成 ! 


比 CountDownLatch 略 微 强 大 一 些 ，CyclicBarrier 可 以 接收 一 个 参 
数 作 为 barrierAction。 所 谓 barrierAction 就 是 当 计 数 器 一 次 计数 完成 
后 ， 系 统 会 执行 的 动作 。 如 下 构造 男 数 ， 其 中 ，parties 表 示 计 数 总 
数 ， 也 就 是 参与 的 线程 总 数 。 


public CyclicBarrier(int parties, Runnable barrierAction) 


下 面 的 示例 使 用 CydlicBarrier 演 示 了 上 述 司令 命令 士兵 完成 任务 的 
场景 。 


01 public class CyclicBarrierDemo { 


02 public static class Soldier implements Runnable { 
03 private String soldier; 

04 private final CyclicBarrier cyclic; 

05 

06 Soldier(CyclicBarrier cyclic, String soldierName) { 
07 this.cyclic = cyclic; 

08 this.soldier = soldierName; 

09 } 

10 

11 public void run() { 

12 try { 


13 // 等 待 所 有 士兵 到 齐 


14 
15 
16 
i 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 


cyclic.await(); 
dowork(); 
// 等 待 所 有 士兵 完成 工作 


cyclic.await(); 


} catch (InterruptedException e) { 
e.printStackTrace(); 
} catch (BrokenBarrierException e) { 


e.printStackTrace(); 


void dowork() { 


try { 
Thread.sleep(Math.abs(new 


Random().nextInt()%10000) ); 


28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 


} catch (InterruptedException e) { 
e.printStackTrace(); 


J 


System.out.println(soldier + " :任务 完成 ") ; 


public static class BarrierRun implements Runnable { 
boolean flag; 
int N; 
public BarrierRun(boolean flag, int N) { 


this.flag = flag; 


40 this.N = N; 

41 } 

42 

43 public void run() { 

44 if (flag) { 

45 System.out.println(" 司 令 :[ 士 兵 " + N + "个 ， 任务 
ee: 

46 } else { 


47 System.out.println(" 司 令 :[ 士 兵 " + N + "个 ， 集 合 


48 flag = true; 


53 public static void main(String args[]) throws 


InterruptedException { 


54 final int N = 10; 

55 Thread[] allSoldier=new Thread[N] ， 

56 boolean flag = false; 

57 CyclicBarrier cyclic = new CyclicBarrier(N, new 


BarrierRun(flag, N)); 


58 // 设 置 屏障 点 ， 主 要 是 为 了 执行 这 个 方法 

59 System.out.println(" 集 合 队伍 ! "); 

60 for (int 1 = 0; 1 < Na r) { 

61 System.out.println("- "+i+" 报道 ! "); 


62 allSoldier[i]=new Thread(new Soldier(cyclic, "£ 


人 


63 allSoldier[i].start(); 


上 述 代码 第 57 行 ， 创 建 了 CydlicBarrier 实 例 ， 并 将 计数 姻 设 置 为 
10， 并 要 求 在 计数 器 达到 指标 时 ， 执 行 第 43 行 的 run0 方 法 。 每 一 个 士 
兵 线 程 会 执行 第 11 行 定义 的 run(0) 方 法 。 在 第 14 行 ， 每 一 个 士兵 线程 都 
会 等 待 ， 直 到 所 有 的 士兵 都 集合 完毕 。 和 集合 完毕 后 ， 意 味 着 
CydlicBarrier 的 一 次 计数 完成 ， 当 再 一 次 调用 CyclicBarrier.await() 时 ， 
会 进行 下 一 次 计数 。 第 15 行 ， 模 拟 了 士兵 的 任务 。 当 一 个 士兵 任务 执 
行 完毕 后 ， 他 束 会 要 求 CyclicBarrier 开 始 下 一 次 计数 ， 这 次 计数 主要 目 
的 是 监控 是 否 所 有 的 士兵 都 已 经 完成 了 任务 。 一 旦 任务 全 部 完成 ， 第 
35 行 定义 的 BarrierRun 束 会 被 调用 ， 打印 相关 信息 。 


上 述 代码 的 执行 输出 如 下 : 


集合 队伍 ! 

士兵 0 报道 ! 

// 篇 幅 有 限 ， 省 略 其 他 几 个 士兵 
士兵 9 报道 ! 


司令 :[ 士 兵 10 个 ， 集 合 完毕 ! ] 
士兵 0: 任 务 完成 

， 省 略 其 他 几 个 士兵 
士兵 4: 任 务 完成 
司令 :[ 士 兵 10 个 ， 任 务 完成 ! ] 
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整个 工作 过 程 的 图 示 如 图 3.2 所 示 。 


PORWR 


图 3.2 ”CydlicBarrier 工 作 示 意图 


alu 


CyclicBarrier.await() 方法 可 能 会 抛 出 两 个 异常 。 一 个 
InterruptedException， 也 残 是 在 等 街 过 程 中 ， 线 程 被 中 断 ， 应 该 说 这 是 
一 个 非常 通用 的 异常 。 大 部 分 迫使 线程 等 待 的 方法 都 可 能 会 抛 出 这 个 
异常 ， 使 得 线程 在 等 待 时 依然 可 以 啊 应 外 部 紧急 事件 。 男 外 一 个 异常 
则 是 CyclicBarrier 特 有 的 BrokenBarrierException。 一 旦 过 到 这 个 异常 ， 
则 表示 当前 的 CyclicBarrier 已 经 破损 了 ， 可 能 系统 已 经 没有 办 法 等 竺 所 
有 线程 到 齐 了 。 如 有 果 继 续 等 待 ， 可 能 残 是 徒 玫 无 功 的 ， 因 此 ， 还 是 束 
地 散 货 ， 打 道 回 府 吧 ! 上 述 代码 第 18~22 行 处 理 了 这 2 种 异常 。 


如 采 我 们 在 上 述 代 码 的 第 63 行 后 ， 插 入 以 下 代码 ， 使 得 第 5 个 士兵 
线程 产生 中 断 : 


if(i==5){ 


allSoldier[0].interrupt(); 


如 有 果 这 样 做 ， 我 们 很 可 能 就 会 得 到 1 个 InterruptedException 和 9 个 
BrokenBarrierException。 这 个 InterruptedException 就 是 被 中 断 线 程 抛 出 
的 。 而 其 他 9 个 BrokenBarrierException， 则 是 等 竺 在 当前 CyclicBarrier 
上 的 线程 抛 出 的 。 这 个 异常 可 以 避免 其 他 9 个 线程 进行 永久 的 、 无 谓 的 
等 待 〈 因 为 其 中 一 个 线程 已 经 被 中 断 ， 等 竺 是 没有 结果 的 ) 。 


3.1.7 线程 阻塞 工具 类 : 
LockSupport 


LockSupport 是 一 个 非常 方便 实用 的 线程 阻塞 工具 ， 它 可 以 在 线程 
内 任意 位 置 让 线程 阻塞 。 和 Thread.suspendO0 相 比 ， 它 弥补 了 由 于 
resume0 在 前 发 生 ， 导 致 线程 无 法 继续 执行 的 情况 。 和 Object.waitO 相 
比 ， 它 不 需要 移 获 得 某 个 对 象 的 锁 ， 也 不 会 抛 出 InterruptedException 寞 
Eo 

LockSupport 的 静态 方法 parkO 可 以 阻塞 当前 线程 ， 类 似 的 还 有 
parkNanos()、parkUntil0) 等 方法 。 它 们 实现 了 一 个 限时 的 等 每 。 


大 家 应 该 还 记得 ， 我 们 在 第 2 章 中 提 到 的 那个 有 天 suspend() 永 久 卡 
死 线程 的 例子 吧 ! 现在 ， 我 们 可 以 用 LockSupport 重 写 这 个 程序 : 


01 public class LockSupportDemo { 

02 public static Object u = new Object(); 

03 static ChangeObjectThread Eí = new 
ChangeObjectThread("t1i"); 

04 static ChangeObjectThread t2 = new 
ChangeObjectThread("t2"); 


05 


06 public static class ChangeObjectThread extends Thread { 
07 public ChangeObjectThread(String name){ 

08 super . setName (name); 

09 } 

10 @Override 

11 public void run() { 

12 synchronized (u) { 

13 System.out.println("in "+getName()); 

14 LockSupport.park(); 

15 } 

16 } 

17 } 

18 

19 public static void main(String[] args) throws 


InterruptedException { 


20 Hstta 

21 Thread.sleep(100); 

22 t2.start(); 

23 LockSupport.unpark(t1); 
24 LockSupport.unpark(t2); 
25 t1.join(); 

26 t2.join(); 

27 } 


注意 ， 这 里 只 是 将 原来 的 suspend0 和 resume0 方 法 用 parkO 和 
unpark0) 方 法 做 了 替换 。 当 然 ， 我 们 依然 无 法 保证 unpark0) 方 法 发 生 在 
park0 方 法 之 后 。 但 是 执行 这 段 代 码 ， 你 会 发 现 ， 它 上 自始至终 都 可 以 正 
常 的 结束 ， 不 会 因为 park() 方 法 而 导致 线程 永久 性 的 挂 起 。 


这 征 因 为 LockSupport 类 使 用 类 似 信 号 量 的 机 制 。 它 为 每 一 个 线程 
准备 了 一 个 许可 ， 如 果 许 可 可 用 ， 那 么 park() 芳 数 会 并 即 返 回 ， 并 且 消 
费 这 个 许可 (也 就 是 将 许可 变 为 不 可 用 ) ， 如 果 许可 不 可 用 ， 就 会 阻 
塞 。 而 unparkO 则 使 得 一 个 许可 变 为 可 用 (但 是 和 信号 量 不 同 的 是 ， 许 
可 不 能 票 加 ， 你 不 可 能 拥有 超过 一 个 许可 ， 它 永远 只 有 一 个 ) 


这 个 特点 使 得 : 即使 tnparkO 操 作 发 生 在 park0 之 前 ， 它 也 可 以 使 
下 一 次 的 park0 操 作 立 即 返回 。 这 也 就 是 上 述 代 码 可 顺利 结束 的 主要 原 


同时 ， 处 于 parkO 挂 起 状态 的 线程 不 会 像 suspend0 那 样 还 给 出 一 个 
令 人 费解 的 Runnable 的 状态 。 它 会 非常 明确 地 给 出 一 个 WAITING 状 
态 ， 甚 至 还 会 标注 是 park0 引 起 的 : 


"ti" #8 prio=5 os_prio=0 tid=0x00b1a400 nid=0x1994 waiting on 
condition [0x1619f000 | 
java.lang.Thread.State: WAITING (parking) 
at sun.misc.Unsafe.park(Native Method) 
at 
java.util.concurrent.locks.LockSupport.park(LockSupport. java: 30 
4) 
at 


geym.conc.ch3.1s.LockSuppor tDemo$ChangeObjectThread. run(LockSup 


portDemo. java:18) 


- locked <0x048b2680> (a java.lang.Object) 


3 DBE FT AT DA AT BS Ib 7 E o ED, WO AR RBE H park(Object) EX 
数 ， 还 可 以 为 当前 线程 设置 一 个 阻 窟 对 象 。 这 个 阻 窗 对 象 会 出 现在 线 
程 Dump 中 。 这 样 在 分 析 问 题 时 ， 丈 更 加 方便 了 。 


比如 ， 如 果 我 们 将 上 述 代码 第 14 行 的 parkO 改 为 : 


LockSupport.park(this); 


那么 在 线程 Dump 时 ， 你 可 能 会 看 到 如 下 信息 : 


"ti" #8 prio=5 os_prio=0 tid=0x0117ac00 nid=0x2034 waiting on 
condition [0x15d0f000 | 
java.lang.Thread.State: WAITING (parking) 
at sun.misc.Unsafe.park(Native Method) 
- parking to wait for <0x048b4738> (a 
geym.conc.ch3.1s.LockSupport- 
Demo$ChangeObjectThread ) 
at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:17 
5) 
at 
geym.conc.ch3.1s.LockSupportDemo$ChangeObjectThread.run 
(LockSupportDemo. java: 18) 
- locked <0x048b2808> (a java.lang.Object) 


意 ， 在 堆栈 中 ， 我 们 甚至 还 看 到 了 当前 线程 等 竺 的 对 象 ， 这 里 
a Š 


除了 有 定时 阻塞 的 功能 外 ，LockSupport.park0O 还 能 支持 中 断 影 
啊 。 但 是 和 其 他 接收 中 断 的 画 样 ，LockSupport.park() 不 会 抛 
出 InterruptedException 异 常 。 它 只 是 会 默默 的 返回 ， 但 是 我 们 可 以 从 
Thread.interrupted() 等 方法 获得 中 断 标 记 。 


01 public class LockSupportiIntDemo { 


02 public static Object u = new Object(); 

03 static ChangeObjectThread t1 = new 
ChangeObjectThread("t1i"); 

04 static ChangeObjectThread t2 = new 
ChangeObjectThread("t2"); 

05 

06 public static class ChangeObjectThread extends Thread { 
07 public ChangeObjectThread(String name){ 

08 super .setName(name); 

09 } 

10 @Override 

Wl public void run() { 

12 synchronized (u) { 

13 System.out.println("in "+getName()); 

14 LockSupport.park(); 

15 if(Thread.interrupted()){ 

16 System.out.printin(getName()+" 被 中 断 


a 


23 


} 
System.out ,println(getName()+" 执 行 结束 " ) ， 


public static void main(String[] args) throws 


InterruptedException { 


24 
25 
26 
27 


注意 
以 蕊 上 响应 这 个 中 断 ， 并 且 返 回 。 之 后 在 外 面 等 待 的 世 才 可 以 进入 临 
界 区 ， 并 最 终 由 LockSupport.unpark(t2) 操 作 使 其 运行 结束 。 


in t1 


ti 被 


PIT T 


t1 执行 结束 


in t2 


t2 执 行 结束 


ti.start(); 
Thread.sleep(100) ; 
t2.start(); 
ti.interrupt(); 


LockSupport.unpark(t2); 


述 代码 在 第 27 行 ， 中 断 了 处 于 park0 状 态 的 tt。 之 后 ，tL 可 


3.2 ”线程 复 用 : 线程 池 


多 线程 的 软件 设计 方法 确实 可 以 最 大 限度 地 发 挥 现代 多 核 处 理 右 
的 计算 能 力 ， 提 高 生产 系统 的 否 吐 量 和 性 能 。 但 是 ， 若 不 加 控制 和 管 
理 的 随意 使 用 线程 ， 对 系统 的 性 能 反而 会 产生 不 利 的 影响 。 


一 种 最 为 稍 单 的 线程 创建 和 回收 的 方法 类 似 如 下 代码 : 


new Thread(new Runnable(){ 
@Override 
public void run() { 
//do sth. 


j 
}).start(); 


以 上 代码 创建 了 一 个 线程 ， 并 在 run() 方 法 结束 后 ， 自 动 回收 该 线 
程 。 在 简单 的 应 用 系统 中 ， 这 段 代 码 并 没有 太 多 问题 。 但 是 在 真实 的 
生产 环境 中 ， 系 统 由 于 真实 环境 的 需要 ， 可 能 会 开启 很 多 线程 来 支撑 
其 应 用 。 而 当 线 程 数量 过 大 时 ， 反 而 会 耗 尽 CPU 和 内 存 资源 。 


首先 ， 虽 然 与 进程 相 比 ， 线 程 是 一 种 轻 量 级 的 工具 ， 但 其 创建 和 
关闭 依然 需要 花费 时 间 ， 如 有 果 为 每 一 个 小 的 任务 都 创建 一 个 线程 ， 很 
有 可 能 出 现 创建 和 销 或 线程 所 占用 的 时 间 大 于 该 线程 真实 工作 所 消耗 
的 时 间 的 情况 ， 反 而 会 得 不 偿 失 。 


其 次 ， 线 程 本 和 喘 也 是 要 占用 内 存 空间 的 ， 大 量 的 线程 会 抢占 宝贵 
的 内 存 资源 ， 如 果 处 理 不 当 ， 可 能 会 导致 Out of Memory 异 常 。 即 便 没 


有 ， 大 量 的 线程 回收 也 会 给 GC 市 来 很 大 的 压力 ， 延 长 GC 的 停顿 时 
间 。 


因此 ， 对 线程 的 使 用 必须 掌握 一 个 度 ， 在 有 限 的 范围 内 ， 增 加 线 
程 的 数量 可 以 明显 提高 系统 的 吞吐 量 ， 但 一 旦 超出 了 这 个 范围 ， 大 量 
的 线程 只 会 拖 震 应 用 系统 。 因 此 ， 在 生产 环境 中 使 用 线程 ， 必 须 对 其 
加 以 控制 和 管理 。 


注意 : 在 实际 生产 环境 中 ， 线 程 的 数量 必须 得 到 控制 。 盲 目的 大 
量 创建 线程 对 系统 性 能 是 有 伤害 的 。 


3.2.1 什么 是 线程 池 


为 了 避免 系统 频繁 地 创建 和 销毁 线程 ， 我 们 可 以 让 创建 的 线程 进 
行 复 用 。 如 条 大 家 进行 过 数据 库 开 发 ， 对 数据 库 连 接 池 应 该 不 会 阳 
生 。 为 了 避免 每 次 数据 库 碍 询 都 重新 建立 和 销 驶 数据 库 连 接 ， 我 们 可 
以 使 用 数据 库 连 接 池 维 护 一 些 数 据 库 连 搂 ， 让 他 们 长 期 保持 在 一 个 激 
活 状 态 。 当 系统 需要 使 用 数据 库 时 ， 并 不 古 创建 一 个 新 的 连接 ， 而 古 
从 连接 池 中 获得 一 个 可 用 的 连接 即 可 。 反 之 ， 当 需要 关闭 连接 时 ， 并 
不 真 的 把 连接 关闭 ， 而 是 将 这 个 连接 “还 ?给 连接 池 即 可 。 通 过 这 种 方 
式 ， 可 以 节约 不 少 创建 和 销 驱 对 象 的 时 间 。 


线程 池 也 是 类 似 的 概念 。 线 程 池 中 ， 总 有 那么 几 个 活跃 线程 。 当 
你 需要 使 用 线程 时 ， 可 以 从 池子 中 随便 拿 一 个 空腹 线程 ， 当 完成 工作 
时 ， 并 不 急 厦 关闭 线程 ， 而 是 将 这 个 线程 退回 到 池子 ， 方 便 其 他 人 使 
用 。 


简 而 言 之 ， 在 使 用 线程 池 后 ， 创 建 线程 变 成 了 从 线程 池 获 得 空闲 
线程 ， 天 闭 线程 变 成 了 疝 池 子 归还 线程 ， 如 图 3.3 所 示 。 
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图 3-3 ”线程 池 的 作用 


3.2.2 ”不 要 重复 发 明 轮 子 : JDK 对 线 
程 池 的 支持 


为 了 能 够 更 好 地 控制 多 线程 ，JDK 提 供 了 一 套 Executor 框 架 ， 帮 助 
开发 人 员 有 效 地 进行 线程 兵制， 其 本 质 就 是 一 个 线程 池 。 它 的 核心 成 
员 如 图 3.4 所 示 。 


a Executor AbstractExecutorService Thread PoolExecutor 


k 


+ execute (Runnable command) 


A 


9 ExecutorService | Executors 
| 
+ shutdown () P + newFixedThreadPool (int n Threads) : ExecutorService 
+ isShutdown () : boolean D + newSingleThreadExecutor () : ExecutorService 
+ isTerminated () : boolean + newCachedThreadPool () : ExecutorService 
+ submit (Callable task) : Future + newSingleThreadScheduledExecutor () : ScheduledExecutorSerice 
T | 
00000000 
& ScheduledExecutorService 


+ schedule (Runnable command, long delay, TimeUnit unit) : ScheduledFuture 


图 3-4 ”Executor 框 架 结 构图 


以 上 成 员 均 在 java.util.concurrent 包 中 ， 是 JDK 并 发 包 的 核心 类 。 
el OO SEES ese en a 
工厂 的 角色 ， 通 过 Executors 可 以 取得 一 个 拥有 特定 功能 的 线程 池 。 从 
UML 图 中 亦 可 知 ，ThreadPoolExecutor 类 实现 了 Executor 接 口 ， 因 此 通 
过 这 个 接口 ， 任 何 Runnable 的 对 象 都 可 以 被 ThreadPoolExecutor 线 程 池 
调度 。 


Executor 框 架 提 供 了 各 种 类 型 的 线程 池 ， 主 要 有 以 下 工厂 方法 : 


public static ExecutorService newFixedThreadPool(int nThreads) 
public static ExecutorService newSingleThreadExecutor() 

public static ExecutorService newCachedThreadPool( ) 

public static ScheduledExecutorService 
newSingleThreadScheduledExecutor ( ) 

public static ScheduledExecutorService 


newScheduledThreadPool(int corePoolSize) 


以 上 工 广 方法 分 别 返回 具有 不 同 工 作 特性 的 线程 池 。 这 些 线程 池 
工厂 方法 的 具体 说 明 如 下 。 


newFixedThreadPool(0 方 法 : 该 方法 返回 一 个 固定 线程 数量 的 线 
程 池 。 该 线程 池 中 的 线程 数量 始终 不 变 。 当 有 一 个 新 的 任务 提 
交 时 ， 线 程 池 中 车 有 空 内 线程 ， 则 立即 执行 。 若 没有 ， 则 新 的 
任务 会 被 暂 存 在 一 个 任务 队列 中 ， 竺 有 线程 空 亲 时 ， 便 处 理 在 
任务 队列 中 的 任务 。 

newSingleThreadExecutor() 方 法 : 该 方法 返回 一 个 只 有 一 个 线程 
的 线程 池 。 若 多 余 一 个 任务 被 提交 到 该 线程 池 ， 任 务 会 被 保存 
在 一 个 任务 队列 中 ， 待 线程 空间 ， 按 先入 先 出 的 顺序 执行 队列 
中 的 任务 。 

newCachedThreadPool0) 方 法 : 该 方法 返回 一 个 可 根据 实际 情况 
调整 线程 数量 的 线程 池 。 线 程 池 的 线程 数量 不 确定 ， 但 若 有 空 
内 线程 可 以 复 用 ， 则 会 优先 使 用 可 复 用 的 线程 。 若 所 有 线程 均 
在 工作 ， 又 有 新 的 任务 提交 ， 则 会 创建 新 的 线程 处 理 任 务 。 所 
有 线程 在 当前 任务 执行 完毕 后 ， 将 返回 线程 池 进 行 复 用 。 
newSingleThreadScheduledExecutor() 方 法 : 该 方法 返回 一 个 
ScheduledExecutorService 对象， 线程 池 大 小 为 1。 
ScheduledExecutorService 接 口 在 ExecutorService 接 口 之 上 扩展 了 
在 给 定时 间 执 行 某 任务 的 功能 ， 如 在 某 个 固定 的 延 时 之 后 执 
行 ， 或 者 周期 性 执行 某 个 任务 。 

newScheduledThreadPool0 方法 : 该 方法 也 返回 一 个 
ScheduledExecutorService 对象， 但 该 线程 池 可 以 指定 线程 数 


E, 


EHO 


1. 固定 大 小 的 线程 池 


这 里 ， 我 们 以 newFixedThreadPool0 为 例 ， 简 单 地 展示 线程 池 的 使 
用 : 


01 public class ThreadPoolDemo { 


02 public static class MyTask implements Runnable { 

03 @Override 

04 public void run() { 

05 System.out.println(System.currentTimeMillis() + 
":Thread ID:" 

06 + Thread.currentThread().getId()); 

07 try { 

08 Thread.sleep(1000) ; 

09 } catch (InterruptedException e) { 

10 e.printStackTrace(); 

11 } 

12 } 

13 } 

14 

L5 public static void main(String[] args) { 

16 MyTask task = new MyTask(); 

17 ExecutorService es = 


Executors.newFixedThreadPool(5); 


18 FOr (ime t s 0y Oe aa 
19 es.submit(task); 

20 } 

21 } 


上 述 代 码 中 ， 第 17 行 创建 了 固定 大 小 的 线程 池 ， 内 有 5 个 线程 。 在 
第 19 行 ， 依 次 同 线 程 池 提 交 了 10 个 任务 。 此 后 ， 线 程 池 束 会 安排 调度 
这 10 个 任务 。 每 个 任务 都 会 将 目 己 的 执行 时 间 和 执行 这 个 线程 的 ID 打 
印 出 来 ， 并 且 在 这 里 ， 安 排 每 个 任务 要 执行 1 秒 钟 。 


执行 上 述 代 码 ， 可 以 得 到 类 似 以 下 输出 : 


1426510293450:Thread ID:8 
1426510293450:Thread ID:9 
1426510293450:Thread ID:12 
1426510293450:Thread ID:10 
1426510293450:Thread ID:11 
1426510294450:Thread ID:12 
1426510294450:Thread ID:11 
1426510294450:Thread ID:8 
1426510294450:Thread ID:10 
1426510294450:Thread ID:9 


这 个 输出 就 表示 这 10 个 线程 的 执行 情况 。 很 显然 ， 前 5 个 任务 和 后 
5 个 任务 的 执行 时 间 正 好 相差 1 秒 钟 《注意 时 间 戳 的 单位 是 毫秒 ) ， 并 
且 前 5 个 任务 的 线程 ID 和 后 5 个 任务 也 是 完全 一 致 的 〈 都 是 8、 9、10、 
11、12) 。 这 说 明 在 这 10 个 任务 中 ， 是 分 成 2 批 次 执行 的 。 这 也 完全 符 
合 一 个 只 有 5 个 线程 的 线程 池 的 行为 。 


有 兴趣 的 读者 可 以 将 其 改造 成 newCachedThreadPool0 ， 看 看 任务 
的 分 配 情况 会 有 何 变 化 ? 


2. 计划 任务 


另外 一 个 值得 注意 的 方法 是 newScheduledThreadPool0)。 它 返回 一 
个 ScheduledExecutorService 对 象 ， 可 以 根据 时 间 需 要 对 线程 进行 调 
度 。 它 的 一 些 主要 方法 如 下 : 


public ScheduledFuture<?> schedule(Runnable command, long 


delay, TimeUnit unit); 


public ScheduledFuture<?> scheduleAtFixedRate(Runnable 
command, 

long 
initialDelay, 


long period, 
TimeUnit 
unit); 


public ScheduledFuture<? > schedulewithFixedDelay (Runnable 


command, 
long 
initialDelay, 
long delay, 
TimeUnit 
unit); 


与 其 他 几 个 线程 池 不 同 ，ScheduledExecutorService 并 不 一 定 会 立 
即 安排 执行 任务 。 它 其 实 是 起 到 了 计划 任务 的 作用 。 它 会 在 指定 的 时 
间 ， 对 任务 进行 调度 。 如 果 大 家 使 用 过 Linux 下 的 crontab 工 具 应 该 就 能 
很 容易 地 理解 它 了 。 


作为 说 明 ， 这 里 给 出 了 三 个 方法 。 方 法 schedule() 会 在 给 定时 间 ， 
对 任务 进行 一 次 调度 © F 法 scheduleAtFixedRate() 和 


scheduleWithFixedDelay0O 会 对 任务 进行 周期 性 的 调度 。 但 是 两 者 有 一 
点 小 小 的 区 别 ， 如 图 3.5 所 示 。 
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图 3.5 ”FixedRate 和 FixDelay 区 别 


对 于 FixedRate 方 式 来 说 ， 任 务 调度 的 频率 是 一 定 的 。 它 是 以 上 一 
个 任务 开始 执行 时 间 为 起 点 ， 之 后 的 period 时 间 ， 调 度 下 一 次 任务 。 
而 FixDelay 则 是 在 上 一 个 任务 结束 后 ， 表 经 过 delay 时 间 进 行 任务 调 
度 。 


由 于 担心 我 的 解释 不 够 周全 ， 我 也 很 乐意 将 官方 文档 中 的 描述 贴 
出 来 供 大 家 参考 ， 从 而 可 以 更 精确 地 理解 两 者 的 兰 别 : 


e scheduleAtFixedRate 


o Creates and executes a periodic action that becomes enabled first 
after the given initial delay, and subsequently with the given 
period; that is executions will commence after initialDelay then 
initialDelay+period, then initialDelay + 2 * period, and so on. 

翻译: 创建 一 个 周期 性 任务 。 任 务 开始 于 给 定 的 初始 延 时 。 
后 续 的 任务 按照 给 定 的 周期 进行 : 后 续 第 一 个 任务 将 会 在 


initialDelay+period 时 执行， 后 续 第 二 个 任务 将 在 
initialDelay+2*period 时 进行 ， 依 此 类 推 。 


。 scheduleWithFixedDelay 


o Creates and executes a periodic action that becomes enabled first 
after the given initial delay, and subsequently with the given delay 
between the termination of one execution and the commencement 
of the next. 

o 翻译 : 创建 并 执行 一 个 周期 性 任务 。 任 务 开始 于 初始 延 时 时 
间 ， 后 续 任 务 将 会 按照 给 定 的 延 时 进行 ， 即 上 一 个 任务 的 结 
束 时 间 到 下 一 个 任务 的 开始 时 间 的 时 间 差 。 


下 面 的 例子 使 用 scheduleAtFixedRate() 方 法 调度 一 个 任务 。 这 个 任 
务 会 执行 1 秒 钟 时 间 ， 调 度 周期 是 2 秒 。 也 就 是 说 每 2 秒 钟 ， 任 务 就 会 被 
执行 一 次 。 


01 public class ScheduledExecutorServiceDemo { 
02 public static void main(String[] args) { 
03 ScheduledExecutorService 


ses=Executors.newScheduledThreadPool(10); 


04 // 如 果 前 面 的 任务 没有 完成 ， 则 调度 也 不 会 启动 

05 ses.scheduleAtFixedRate(new Runnable() { 
06 @Override 

07 public void run() { 

08 try { 

09 Thread.sleep(1000) ; 


10 


System.out.printin(System.currentTimeMillis()/1000); 
11 } catch (InterruptedException e) { 
12 e.printStackTrace(); 

13 } 

14 } 

15 }, ©, 2, TimeUnit.SECONDS); 


执行 上 述 代码 ， 一 种 输出 的 可 能 如 下 : 


1426515345 
1426515347 
1426515349 
1426515351 


上 述 输 出 的 单位 是 秒 。 可 以 看 到 ， 时 间 间 隔 是 2 秒 。 


这 里 还 想 说 一 个 有 意思 的 事情 ， 如 果 任 务 的 执行 时 间 超 过 调度 时 
间 ， 会 发 生 什 么 情况 呢 ? 比 如 ， 这 里 调度 周期 是 2 秒 ， 如 果 任 务 的 执行 
时 间 是 8 秒 ， 是 不 是 会 出 现 多 个 任务 堆 琶 在 一 起 呢 ? 

实际 上 ，ScheduledExecutorService 不 会 让 任务 堆 著 出 现 。 我 们 将 
第 9 行 的 代码 改 为 : 


Thread.sleep(8000); 


再 执行 上 述 代 码 ， 你 就 会 发 现任 务 的 执行 周期 不 再 是 2 秒 ， 而 古 变 
成 了 8 秒 。 如 下 所 示 ， 是 一 种 可 能 的 结果 。 


1426516323 
1426516331 
1426516339 
1426516347 
1426516355 


也 就 是 说 ， 周 期 如 有 果 太 短 ， 那 么 任务 就 会 在 上 一 个 任务 结束 后 ， 
立即 被 调用 。 可 以 想象 ， 如 果 采 用 scheduleWithFixedDelay()， 并 且 按 
照 修改 8 秒 ， 调 度 周 期 2 秒 计 ， 那 么 任务 的 实际 间隔 将 是 10 秒 ， 大 家 可 
以 目 行 尝试 。 


男 外 一 个 值得 注意 的 问题 是 ， 调 度 程序 实际 上 并 不 保证 任务 会 无 
限期 的 持续 调用 。 如 果 任 务 本 喘 抛 出 了 异常 ， 那 么 后 续 的 所 有 执行 都 
会 被 中 断 ， 因 此 ， 如 末 你 想 让 你 的 任务 持续 稳定 的 执行 ， 那么 做 好 异 
党 处 理 束 非 常 重要 ， 否 则 ， 你 很 有 可 能 观察 到 你 的 调度 紫 无 疾 而 终 。 


注意 : 如 果 任 务 直到 异常 ， 那 么 后 续 的 所 有 子 任务 都 会 停止 调 
度 ， 因 此 ， 必 须 保证 异常 被 及 时 处 理 ， 为 周期 性 任务 的 稳定 调度 
提供 条 件 * 


3.2.3 MRE: 核心 线程 池 的 内 部 
实现 


对 于 核心 的 几 个 线程 池 ， 无 论 是 newFixedThreadPool0 方 法 、 
newSingleThreadExecutor0O 还 是 newCachedThreadPool0) 方 法 ， 虽 然 看 起 
来 创建 的 线程 有 着 完全 不 同 的 功能 特点 ， 但 其 内 部 实现 均 使 用 了 
ThreadPoolExecutor 实 现 。 下 面 给 出 了 这 三 个 线程 池 的 实现 方式 : 


public static ExecutorService newFixedThreadPool(int nThreads) 
{ 
return new ThreadPoolExecutor(nThreads, nThreads, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue < 


Runnable>()); 


i: 


public static ExecutorService newSingleThreadExecutor() { 
return new FinalizableDelegatedExecutorService 
(new ThreadPoolExecutor(1, 1, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue < 


Runnable>())); 
} 


public static ExecutorService newCachedThreadPool() { 
return new ThreadPoolExecutor(0, Integer .MAX_VALUE, 
60L, TimeUnit.SECONDS, 
new SynchronousQueue < 


Runnable>()); 


j 


由 以 上 线程 池 的 实现 代码 可 以 看 到 ， 它 们 都 只 是 
ThreadPoolExecutor 类 的 封装 。 为 何 ThreadPoolExecutor 有 如 此 强大 的 
功能 呢 ? 来 看 一 下 ThreadPoolExecutor 最 重要 的 构造 卫 数 : 


public ThreadPoolExecutor(int corePoolSize, 
int maximumPoolSize, 
long keepAliveTime, 
TimeUnit unit, 
BlockingQueue<Runnable> workQueue, 
ThreadFactory threadFactory, 


RejectedExecutionHandler handler) 


函数 的 参数 合 义 如 下 。 


corePoolSize: 指定 了 线程 池 中 的 线程 数量 。 

maximumPoolSize: 指定 了 线程 池 中 的 最 大 线程 数量 。 
keepAliveTime: 当 线 程 池 线程 数量 超过 corePoolSize 时 ， 多 余 的 
空闲 线 程 的 存活 时 间 。 即 ， 超 过 corePoolSize 的 空 亲 线程 ， 在 多 
长 时 间 内 ， 会 被 销毁 。 

unit: keepAliveTime 的 单位 。 

workQueue: 任务 队列 ， 被 提交 但 尚未 被 执行 的 任务 。 
threadFactory: 线程 工厂 ， 用 于 创建 线程 ， 一 般 用 默认 的 即 
可 。 

handler: 拒绝 策略 。 当 任务 太 多 来 不 及 处 理 ， 如 何 拒绝 任务 。 


以 上 参数 中 ， 大 部 分 都 很 答 单 ， 只 有 workQueue 和 handler 需 要 进 
行 详 细 说 明 。 

参数 workQueue 指 被 提交 但 未 执行 的 任务 队列 ， 它 是 一 个 
BlockingQueue 接 口 的 对 象 ， 仅 用 于 存放 Runnable 对 象 。 根 据 队 列 功能 


分 类 ， 在 ThreadPoolExecutor 的 构造 芳 数 中 可 使 用 以 下 几 种 
BlockingQueue ° 


。 直接 提交 的 队列 : 该 功能 由 SynchronousQueue 对 象 提 供 。 
SynchronousQueue 是 一 个 特 殊 的 BlockingQueue 
SynchronousQueue 没 有 容量 ， 每 一 个 插入 操作 都 要 等 待 一 个 相 
应 的 删除 操作 ， 反 之 ， 每 一 个 删除 操作 都 要 等 待 对 应 的 插入 操 
作 。 如 采 使 用 SynchronousQueue， 提 区 的 任务 不 会 被 真实 的 保 
存 ， 而 总 是 将 新 任务 提交 给 线程 执行 ， 如 果 没 有 空闲 的 进程 ， 
则 党 试 创建 狐 的 进程 ， 如 果 进 程 数 量 已 经 达到 最 大 值 ， 则 执行 
拒绝 策略 。 因 此 ， 使 用 SynchronousQueue 了 队列， 通常 要 设置 很 
大 的 maximumPoolSize 值 ， 否 则 很 容易 执行 拒绝 策略 。 

有 界 的 任务 队列 : 有 界 的 任务 队列 可 以 使 用 
ArrayBlockingQueue 实 现 。ArrayBlockingQueue 的 构造 范 数 必须 
带 一 个 容量 参数 ， 表 示 该 队列 的 最 大 容量 ， 如 下 所 示 。 


public ArrayBlockingQueue(int capacity) 


当 使 用 有 界 的 任务 队列 时 ， 者 有 新 的 任务 需要 执行 ， 如 果 线 程 
池 的 实际 线程 数 小 于 corePoolSize， 则 会 优先 创建 新 的 线程 ， 
若 大 于 corePoolSize， 则 会 将 新 任务 加 入 等 待 队 列 。 若 等 得 队 
列 已 满 ， 无 法 加 入 ， 则 在 总 线程 数 不 大 于 maximumPoolSize 的 
前 担 下 ， 创 建新 的 进程 执行 任务 。 者 大 于 maximumPoolSize， 
则 执行 拒绝 策略 。 可 见 ， 有 界 队 列 仅 当 在 任务 队列 装 满 时 ， 才 
可 能 将 线程 数 提升 到 corePoolSize 以 上 上， 换言之 ， 除 非 系统 非 
常 雍 性， 否则 确保 核心 线程 数 维持 在 在 corePoolSize ° 


© 无界 的 任务 队列 : 无 界 任务 队列 可 以 通过 LinkedBlockingQueue 
类 实现 。 与 有 界 队 列 相 比 ， 除 非 系统 资源 耗 尽 ， 否 则 无 界 的 任 
务 队列 不 存在 任务 入 队 失 败 的 情况 。 当 有 新 的 任务 到 来 ， 系 统 
的 线程 数 小 于 corePoolSize 时 ， 线 程 池 会 生成 新 的 线程 执行 任 


， 但 当 系 统 的 线程 数 达到 corePoolSize 后 ， 束 不 会 继续 增加 。 
We 卖 仍 有 新 的 任务 加 入 ， 而 又 没有 空闲 的 线程 资源 ， 则 任务 
直接 进入 队列 等 待 。 寿 任务 创建 和 处 理 的 速度 差异 很 大 ， 无 界 
队列 会 保持 快速 增长 ， 直 到 耗 尽 系统 内 存 。 
优先 任务 队列 : 优先 任务 队列 是 带 有 执行 优先 级 的 队列 。 它 通 
过 PriorityBlockingQueue 实 现 ， 可 以 控制 任务 的 执行 先后 顺序 。 
它 是 一 个 特殊 的 无 界 队 列 。 无 论 是 有 界 队 列 
ArrayBlockingQueue ， 还 是 未 指定 大 小 的 无 界 队 列 
LinkedBlockingQueue 都 是 按照 先进 先 出 算法 处 理 任务 的 。 而 
PriorityBlockingQueue 则 可 以 根据 任务 目 寻 的 优先 级 顺序 先后 执 
行 ， 在 确保 系统 性 能 的 同时 ， 也 能 有 很 好 的 质量 保证 (总 是 确 
保 高 优先 级 的 任务 先 执行 ) 。 


回顾 newFixedThreadPool0 方法 的 实现 。 它 返回 了 一 个 
corePoolSize 和 maximumPoolSize 大 小 一 样 的 ， 并 且 使 用 了 
LinkedBlockingQueue 任 务 队 列 的 线程 池 。 因 为 对 于 固定 大 小 的 线程 池 
而 言 ， 不 存在 线程 数量 的 动态 变化 ， 此 corePoolSize 和 
maximumPoolSize 可 以 相等 。 同 时 ， 它 使 用 无 界 队 列 存 放 无 法 立即 执 
行 的 任务 ， 当 任务 提交 非常 频繁 的 上 时候， 该 队列 可 能 志 速 脱 胀 ， 从 而 
耗 尽 系统 资源 。 


newSingleThreadExecutor() 返回 的 单线 程 线 程 池 ， 是 
newFixedThreadPool() 方 法 的 一 种 退化 ， 只 是 简单 的 将 线程 池 线 程 数 量 
设置 为 1 。 


newCachedThreadPool() 方法 ls 回 corePoolSize 为 0 , 
maximumPoolSize 无 穷 大 的 线程 池 ， 这 意味 着 在 没有 任务 时 ， 该 线程 
池内 无 线程 ， 而 当 任 务 被 提交 时 ， ae Th EH 2S PN RT EE 


务 ， 若 无 空 有 线程 ， 则 将 任务 加 入 SynchronousQueue BA 4!) , Ti 
SynchronousQueue 队 列 是 一 种 直接 提交 的 队列 ， 它 总 会 迫使 线程 池 增 
加 新 的 线程 执行 任务 。 当 任务 执行 完毕 后 ， 由 于 corePoolSize 为 0， 
此 空 内 线程 又 会 在 指定 时 间 内 (60%) 被 回收 。 


对 于 newCachedThreadPool()， 如 果 同 时 有 大 量 任务 被 提交 ， 而 任务 的 
执行 又 不 那么 快 时 ， 那 么 系统 便 会 开启 等 量 的 线程 处 理 ， 这 样 做 法 可 
能 会 很 快 耗 尽 系统 的 资源 。 


注意 : 使 用 自 定义 线程 池 时 ， 要 根据 应 用 的 具体 情况 ， 选 择 合适 

的 并 发 队列 作为 任务 的 缓冲 。 当 线程 资源 紧张 时 ， 不 同 的 并 发 队 

列 对 系统 行为 和 性 能 的 影响 均 不 同 。 

这 里 给 出 ThreadPoolExecutor 线 程 池 的 核心 调度 代码 ， 这 上 段 代 码 也 
充分 体现 了 了 上述 线程 池 的 工作 逻辑 : 


01 public void execute(Runnable command) { 


02 if (command == null) 

03 throw new NullPointerException(); 

04 int c = ctl.get(); 

05 if (workerCountOf(c) < corePoolSize) { 

06 if (addWorker(command, true)) 

07 return; 

08 c = ctl.get(); 

09 } 

10 if (isRunning(c) && workQueue.offer(command)) { 
11 int recheck = ctl.get(); 


12 if (! isRunning(recheck) && remove(command) ) 


13 reject(command); 


14 else if (workerCountOf(recheck) == 0) 
15 addworker(null, false); 

16 } 

17 else if (!addWorker(command, false)) 

18 reject(command); 

19 } 


代码 第 5 行 的 workerCountOfO 函 数 取 得 了 当前 线程 池 的 线程 总 数 。 
当 线 程 总 数 小 于 corePoolSize 核 心 线程 数 时 ， 会 将 任务 通过 addWorker() 
方法 直接 调度 执行 。 否 则 ， 则 在 第 10 行 代码 处 (workQueue.offer()) 进 
入 等 竺 队列 。 如 果 进 入 等 待 队列 失败 (比如 有 界 队 列 到 达 了 上 限 ， 或 
者 使 用 了 SynchronousQueue) ， 则 会 执行 第 17 行 ， 将 任务 直接 提交 给 
线程 池 。 如果 当 前 线程 数 已 经 达到 maximumPoolSize， 则 提交 失败 ， 
束 执 行 第 18 行 的 拒绝 策略 。 


调度 逻辑 可 以 总 结 为 如 图 3.6 所 示 。 
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图 3.6 ”ThreadPoolExecutor 的 任务 调度 逻辑 


3.2.4 ”超人 负载 了 怎么 办 : 拒绝 策略 


ThreadPoolExecutor 的 最 后 一 个 参数 指定 了 拒绝 策略 。 也 就 是 当 任 
务 数量 超过 系统 实际 承载 能 力 时 ， 该 如 何 处 理 呢 ? 这 时 就 要 用 到 拒绝 
策略 了 。 拒 绝 策 略 可 以 说 是 系统 超 负 谷 运 行 时 的 补救 措施 ， 通 常 由 于 
压力 太 大 而 引起 的 ， 也 就 是 线程 池 中 的 线程 已 经 用 完了 ， 无 法 继续 为 
新 任务 服务 ， 同 时 ， 等 竺 队列 中 也 已 经 排 满 了 ， 再 也 塞 不 下 新 任务 
了 。 这 时 ， 我 们 就 需要 有 一 套 机 制 ， 合 理 地 处 理 这 个 问题 。 


JDK 内 置 提 供 了 四 种 拒绝 策略 ， 如 图 3.7 所 示 。 


a 9 RejectedExecutionHandler -~ java. util. concurrent 


(CH AbortPolicy - java. util. concurrent. ThreadPoolE: 
(CH CallerRunsPolicy - java. util. concurrent. Thread 
(CH Discard0ldestPolicy - java. util. concurrent. Thr 
(CE DiscardPolicy - java. util. concurrent. ThreadPoo. 


图 3.7”JDK 内 置 的 拒绝 策略 


JDK 内 置 的 拒绝 策略 如 下 。 


。 AbortPolicy 策 略 : 该 策略 会 直接 抛 出 异常 ， 阻 止 系统 正常 工 
作 。 

e CallerRunsPolicy 策 略 : 只 要 线程 池 示 关闭， 该 策略 直接 在 调用 
者 线程 中 ， 运 行当 前 被 丢弃 的 任务 。 显 然 这 样 做 不 会 真 的 丢弃 
任务 , 但 是 ， 任 务 提交 线程 的 性 能 极 有 可 能 会 急剧 下 降 。 

e DiscardOledestPolicy RK: 该 策略 将 丢弃 最 老 的 一 个 请 求 ， 也 

束 是 即将 被 执行 的 一 个 任务 ， 并 党 试 再 次 提交 当前 任务 。 

DiscardPolicy 策 略 : 该 策略 默默 地 丢弃 无 法 处 理 的 任务 ， 不 也 

任何 处 理 。 如 采 人 允许 任务 丢失 ， 我 觉得 这 可 能 是 最 好 的 一 种 方 

案 了 吧 ! 


Lh EAE ng ty E T RejectedExecutionHandlerf#H , Æ MAE 
策略 仍 无 法 满足 实际 应 用 需要 ， 完 全 可 以 目 己 扩展 
RejectedExecutionHandler 接 @ ° RejectedExecutionHandler 的 定 SC 如 
下 : 


public interface RejectedExecutionHandler { 
void rejectedExecution(Runnable r, ThreadPoolExecutor 


executor); 


} 
其 中 r 为 请 求 执行 的 任务 ，executor 为 当前 的 线程 池 。 
下 面 的 代码 简单 地 演示 了 目 定 义 线程 池 和 拒绝 集 略 的 使 用 : 


01 public class RejectThreadPoolDemo { 


02 public static class MyTask implements Runnable { 
03 @Override 

04 public void run() { 

05 System.out.println(System.currentTimeMillis() + 
":Thread ID:" 

06 + Thread.currentThread().getId()); 
07 try { 

08 Thread.sleep(100); 

09 } catch (InterruptedException e) { 

10 e.printStackTrace(); 

11 } 

12 } 


13 } 


14 
15 public static void main(String[] args) throws 


InterruptedException { 


16 MyTask task = new MyTask(); 

17 ExecutorService es = new ThreadPoolExecutor(5, 5, 

18 OL, TimeUnit.MILLISECONDS, 

19 new LinkedBlockingQueue<Runnable> (10), 

20 Executors.defaultThreadFactory(), 

21 new RejectedExecutionHandler(){ 

22 @Override 

23 public void rejectedExecution(Runnable 
r, 

24 ThreadPoolExecutor executor) { 
25 System.out.println(r.toString()+" is 
discard"); 

26 i 

27 }); 

28 for (int i = 0; i < Integer.MAX_VALUE; i++) { 

29 es.submit(task); 

30 Thread.sleep(10); 

31 } 

32 } 

33 } 


上 述 代 码 的 第 17~27 行 目 定 义 了 一 个 线程 池 。 该 线程 池 有 5 个 常 驻 
线程 ， 并 且 最 大 线程 数量 也 是 5 个 。 这 和 固定 大 小 的 线程 池 是 一 样 的 。 
但 是 它 却 拥有 一 个 只 有 10 个 容量 的 等 待 队列 。 因 为 使 用 无 界 队 列 很 可 


能 并 不 是 最 佳 解 决 方案 ， 如 果 任 务 量 极 大 ， 很 有 可 能 会 把 内 存 撑 爆 。 
给 出 一 个 合理 的 队列 大 小 ， 也 是 合乎 种 理 的 选择 。 同 时 ， 这 里 目 定 义 
了 拒绝 策略 ， 我 们 不 扫 出 异常 ， 因 为 万 一 在 任务 提交 端 没 有 进行 异常 
处 理 ， 则 有 可 能 使 得 整个 系统 都 表演 ， 这 极 有 可 能 不 是 我 们 希望 过 到 
的 。 但 作为 必要 的 信息 记录 ， 我 们 将 任务 丢弃 的 信息 进行 打印 ， 当 
然 ， 这 只 比 内 置 的 DiscardPolicy 策 上 略 高 级 那么 一 点 点 。 


由 于 在 这 个 案例 中 ，MyTask 执 行 需要 人 花费 100 晕 秒 ， 因 此 ， 必 然 
会 导致 大 量 的 任务 被 直接 丢弃 。 执 行 上 述 代码 ， 可 能 的 部 分 输出 如 
下 : 


1426597264669:Thread ID:11 
1426597264679:Thread ID:12 
java.util.concurrent.FutureTask@a57993 is discard 


java.util.concurrent.FutureTask@1b84c92 is discard 


可 以 看 到 ， 在 执行 几 个 任务 后 ， 拒 绝 策略 就 开始 生效 了 。 在 实际 
应 用 中 ， 我 们 可 以 将 更 详细 的 信息 记录 到 日 志 中 ， 来 分 析 系 统 的 负 副 
和 任务 丢失 的 情况 。 


325 目 定 义 线 程 创 建 : 
ThreadFactory 


看 了 那么 多 有 天线 程 池 的 介绍 ， 不 知道 大 家 有 没有 思考 过 一 个 基 
本 的 问题 : 那 丈 是 线程 池 中 的 线程 是 从 哪里 来 的 呢 ? 


之 前 我 们 介绍 过 ， 线 程 池 的 主要 作用 是 为 了 线程 复 用 ， 也 融 是 避 
免 了 线程 的 频繁 创建 。 但 是 ， 最 开始 的 那些 线程 从 何 而 来 呢 ? SSR 


是 ThreadFactory ° 


ThreadFactory 是 一 个 接口 ， 它 只 有 一 个 方法 ， 用 来 创建 线程 : 


Thread newThread(Runnable r); 
Stele 2 EATEN, PAVIA TTTE © 


目 定义 线程 池 可 以 帮助 我 们 做 不 少 事 。 比 如 ， 我 们 可 以 跟 踩 线程 
池 完 竟 在 何 时 创建 了 多 少 线程 ， 也 可 以 目 定义 线程 的 名 称 、 组 以 及 优 
先 级 等 信息 ， 甚 至 可 以 任性 地 将 所 有 的 线程 设置 为 守护 线程 。 忌 之 ， 
使 用 目 定义 线程 池 可 以 让 我 们 更 加 目 由 地 设置 池子 中 所 有 线程 的 状 
态 。 下 面 的 案例 使 用 自 定 义 的 ThreadFactory， 一 方面 记录 了 线程 的 创 
建 ， 另 一 方面 将 所 有 的 线程 都 设置 为 守护 线程 ， 这 样 ， 当 主线 程 退出 
后 ， 将 会 强制 销毁 线程 池 。 


01 public static void main(String[ ] args) throws 


InterruptedException { 


02 MyTask task = new MyTask(); 

03 ExecutorService es = new ThreadPoolExecutor(5, 5, 
04 OL, TimeUnit.MILLISECONDS, 

05 new SynchronousęQueue < Runnable>(), 

06 new ThreadFactory(){ 

07 @Override 

08 public Thread newThread(Runnable r) { 


09 Thread t= new Thread(r); 


10 t.setDaemon(true); 


11 System.out.println("create "+t); 
12 return t; 

13 } 

14 } 

15 ); 

16 HOG aime i 0 5 era) a 

17 es.submit(task); 

18 } 

19 Thread.sleep(2000); 

20 } 


3.2.6 ”我 的 应 用 我 做 主 : 扩展 线程 池 


虽然 JDK 已 经 帮 有 我 们 实现 了 这 个 稳定 的 高 性 能 线程 池 。 但 如 采 我 
们 需要 对 这 个 线程 池 做 一 些 扩展 ， 比 如 ， 我 们 想 EEEE 
开始 和 结束 时 间 ， 或 者 其 他 一 些 目 定 义 的 增强 功能 ， 这 时 候 应 该 怎么 
办 呢 ? 


一 个 好 消息 是 : ThreadPoolExecutor 也 是 一 个 可 以 扩展 的 线程 池 。 
它 提 供 了 beforeExecute()、afterExecute() 和 terminated() 三 个 接口 对 线程 
池 进 行 控制 。 


以 beforeExecute() ` afterExecute(.) 为 例 ， 在 
ThreadPoolExecutor. Worker. runTask() 方 法 内 部 提供 了 这 样 的 实现 : 


boolean ran = false; 
beforeExecute(thread, task); 
try { 
task.run(); 
和 
ran = true; 
afterExecute(task, null); 
束 后 
++completedTasks; 
} catch (RuntimeException ex) { 
if (!ran) 


afterExecute(task, ex); 


throw ex; 


mwa 


// 运 行 前 


// 运 行 任 


ThreadPoolExecutor.Worker 是 ThreadPoolExecutor 的 内 部 类 ， 它 是 
一 个 实现 了 Runnable 接 口 的 类 。ThreadPoolExecutor 线 程 池 中 的 工作 线 
程 也 正 是 worker 实 例 。WorkerrunTask(0) 方 法 会 被 线程 池 以 多 线程 模式 
异步 调用 ， 即 Worker.runTask() 会 同时 被 多 个 线程 访问 。 因 此 其 


beforeExecute() 、afterExecute0 接 口 也 将 同时 多 线程 访问 。 


在 默认 的 ThreadPoolExecutor 实 现 中 ， 提 供 了 空 的 beforeExecute() 
和 afterExecute() 实 现 。 在 实际 应 用 中 ， 可 以 对 其 进行 扩展 来 实现 对 线 
程 池 运 行 状态 的 跟踪 ， 输 出 一 些 有 用 的 调试 信息 ， 以 帮助 系统 故障 诊 
断 ， 这 对 于 多 线程 程序 错误 排 奋 是 很 有 帮助 的 。 下 面 演 示 了 对 线程 江 


的 扩展 ， 在 这 个 扩展 中 ， 我 们 将 记录 每 一 个 任务 的 执行 


01 public class ExtThreadPool { 


02 public static class MyTask implements Runnable { 

03 public String name; 

04 

05 public MyTask(String name) { 

06 this.name = name; 

07 } 

08 

09 @Override 

10 public void run() { 

11 System.out.println(" 正 在 执行 " + ":Thread ID:" + 


Thread. currentThread().getId() 


12 + ", Task Name=" + name); 

13 try { 

14 Thread.sleep(100) ; 

15 } catch (InterruptedException e) { 

16 e.printStackTrace(); 

17 } 

18 } 

19 } 

20 

21 public static void main(String[] args) throws 
InterruptedException { 

22 

23 ExecutorService es = new ThreadPoolExecutor(5, 5, OL, 


TimeUnit .MILLISECONDS, 


24 new LinkedBlockingQueue<Runnable>()) { 


25 
26 
r) 
27 
r) 
28 
29 
30 
31 


name); 


@Override 


protected void beforeExecute(Thread t, Runnable 


System.out.printlLn(" 准 备 执行 : " + ((MyTask) 


Throwable t) { 


32 
r) 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 


.hame); 


} 
@Override 
protected void afterExecute(Runnable r, 
System.out.println(" 执 行 完 成 : " + ((MyTask) 
} 
@Override 


protected void terminated() { 


System,out,.printlLn(" 线 程 池 退 出 " ) ; 


}; 

Tor Cink a s (Op i < 5a aaa) f 
MyTask task = new MyTask("TASK-GEYM-" + i); 
es.execute(task); 
Thread.sleep(10); 

} 


es.shutdown(); 


48 } 


上 述 代 码 在 第 23 一 40 行 ,扩展 了 原 有 的 线程 池 ， 实 现 了 
beforeExecute()、afterExecute() 和 和 terminiated() 三 个 方法 。 这 三 个 方法 分 
别 用 于 记录 一 个 任务 的 开始 、 结 束 和 整个 线程 池 的 退出 。 在 第 42 一 43 
行 ， 癌 线程 池 提 交 5 个 任务 ， 为 了 有 更 清晰 的 日 志 ， 我 们 为 每 个 任务 都 
取 了 一 个 不 同 的 名 字 。 第 43 行 使 用 execute() 方 法 提交 任务 ， 细 心 的 读 
者 一 定 发 现 ， 在 之 前 代码 中 ， 我 们 都 使 用 了 submit() 方 法 提交 ， 有 天 两 
考 的 区 别 ， 我 们 将 在 “5.5 节 Future 模 式 ” 中 详细 介绍 。 


在 提交 完成 后 ， 调 用 shutdown() 方 法 关闭 线程 池 。 这 是 一 个 比较 
安全 的 方法 ， 如 有 果 当 前 正 有 线程 在 执行 ，shutdown() 方 法 并 不 会 立即 
又 力 地 终止 所 有 任务 ， 它 会 等 竺 所 有 任务 执行 完成 后 ， 再 关闭 线程 
池 ， 但 它 并 不 会 等 待 所 有 线程 执行 完成 后 再 返回 ， 因 此 ， 可 以 简单 地 
理解 成 shutdownO 只 是 发 送 了 一 个 关闭 信号 而 已 。 但 在 shutdown() 方 法 
执行 后 ， 这 个 线程 池 残 不 能 再 接受 其 他 新 的 任务 了 。 


执行 上 述 代 码 ， 可 以 得 到 类 似 以 下 的 输出 : 


准备 执行 TASK-GEYM-0 


正在 执行 :Thread ID:8, Task Name=TASK-GEYM-0 
准备 执行 : TASK-GEYM-1 


正在 执行 :Thread ID:9,Task Name=TASK-GEYM-1 
准备 执行 ，TASK-GEYM-2 


正在 执行 :Thread ID:10,Task Name=TASK-GEYM-2 
准备 执行 ， TASK-GEYM-3 


正在 执行 ;Thread ID:11,Task Name=TASK-GEYM-3 


准备 执行 : TASK-GEYM-4 


正在 执行 :Thread ID:12, Task Name=TASK-GEYM-4 
执行 完成 : TASK-GEYM-0 
执行 完成 : TASK-GEYM- 
执行 完成 : TASK-GEYM- 


1 
2 
执行 完成 : TASK-GEYM-3 
执行 完成 : TASK-GEYM-4 
线程 池 退 出 


可 以 看 到 ， 所 有 任务 的 执行 前 、 执 行 后 的 时 间 点 以 及 任务 的 名 字 
都 已 经 可 以 捕获 了 。 这 对 于 应 用 程序 的 调试 和 诊断 十 非常 有 帮助 的 。 


3.2.7 ”合理 的 选择 : 优化 线程 池 线 程 
数量 


线程 池 的 大 小 对 系统 的 性 能 有 一 定 的 影响 。 过 大 或 者 过 小 的 线程 
数量 都 无 法 发 挥 最 优 的 系统 性 能 ， 但 是 线程 池 大 小 的 确定 也 不 需要 做 
得 非常 精确 ， 因 为 只 要 避免 极 大 和 极 小 两 种 情况 ， 线 程 池 的 大 小 对 系 
统 的 性 能 并 不 会 影响 太 大 。 一 般 来 说 ， 确 定 线程 池 的 大 小 需要 考虑 
CPU 数量 、 内 存 大 小 等 因素 。 在 《Java Concurrency in Practice) 一 书 
中 给 出 了 一 个 估算 线程 池 大 小 的 经 验 公 式 : 


Ncpu = CPU 的 数量 
Ucpu = 目标 CPU 的 使 用 率 ，0 < Ucpux 1 
W/C = 等 待 时 间 与 计算 时 间 的 比率 


为 保持 处 理 器 达到 期 望 的 使 用 率 ， 最 优 的 池 的 大 小 等 于 : 


Nthreads = Ncpu * Ucpu * (1+ W/C ) 
在 Java 中 ， 可 以 通过 : 


Runtime.getRuntime().availableProcessors() 


取得 可 用 的 CPU 数量 。 


3.2.8 ”堆栈 去 哪里 了 : 在 线程 池 中 寻 
找 堆栈 


大 家 一 定 还 记得 在 上 一 章 中 ， 我 们 详解 介绍 了 一 些 幽 灵 般 的 错 
误 。 我 想 ， 码 农 的 痛 音 也 莫 过 于 此 了 。 多 线程 本 身 克 是 非常 容易 引起 
这 类 错误 的 。 如 果 你 使 用 了 线程 池 ， 那 么 这 种 幽灵 错误 可 能 会 变 得 更 
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下 面 来 看 一 个 人 简单 的 案例 ， 首 和 完 ， 我 们 有 一 个 Runnable 接 口 ， 它 
用 来 计算 两 个 数 的 商 : 


public class DivTask implements Runnable { 
int a,b; 


public DivTask(int a,int b){ 


this.a=a; 
this.b=b; 
} 
@Override 


public void run() { 


double re=a/b; 


System.out.println(re); 


如 条 程序 运行 了 这 个 任务 ， 那 么 我 们 期 望 它 可 以 打印 出 给 定 两 个 
数 的 商 。 现 在 我 们 构造 儿 个 这 样 的 任务 ， 硕 望 程序 可 以 为 我 们 计算 一 
组 给 定数 组 的 商 : 


public static void main(String[ ] args) throws 
InterruptedException, ExecutionException { 
ThreadPoolExecutor pools=new ’ ThreadPoolExecutor(0, 
Integer .MAX_VALUE, 
OL, TimeUnit.SECONDS, 


new SynchronousQueue<Runnable>()); 


for(int 1=0;1<5;i++){ 


pools.submit(new DivTask(100,1)); 


上 述 代 码 将 DivTask 提 交 到 线程 池 ， 从 这 个 for 循 环 来 看 ， 我 们 应 
该 会 得 到 5 个 结果 ， 分 别 是 100 除 以 给 定 的 ji 后 的 商 。 但 如 果 你 真 的 运行 
程序 ， 你 得 到 的 全 部 结果 是 : 


33.0 
50.0 


100 .0 


你 没有 看 错 ! 只 有 4 个 输出 。 也 就 说 是 程序 漏 算 了 一 组 数据 ! 但 更 
不 幸 的 征 ， 程 序 没有 任何 日 六， 没有 任何 错误 提示 ， 融 好 像 一 切 都 正 
彰 一 样 。 在 这 个 简单 的 案例 中 ， 只 要 你 稍 有 经 验 ， 你 残 能 发 现 ， 作 为 
除数 的 i 取 到 了 0， 这 个 缺失 的 值 很 可 能 是 由 于 除 以 0 导致 的 。 但 在 稍 复 
杂 的 业务 场景 中 ， 这 种 错误 足 可 以 让 你 几 天 雁 麻 不振。 


因此 ， 使 用 线程 池 虽 然 古 件 好 事 ， 但 是 还 是 得 处 处 留意 这 
EoD” o 线程 池 很 有 可 能 会 “hc” 挥 程序 抛 出 的 异 第 ， 导 致 我 们 对 程序 
的 错误 一 无 所 知 。 


异常 堆栈 对 于 程序 员 的 重要 性 束 好 像 指南 针对 于 茫茫 大 海上 的 骨 
只 。 没 有 指南 针 ， 船 只 只 能 更 艰难 地 寻找 方向 ， 没 有 有 异常 堆栈 ， 排 查 
问题 时 ， 也 只 能 像 大 海 搞 针 那 样 ， 慢 慢 琢 证 了 。 我 的 一 个 领导 曾经 说 
过 : 最 吕 视 那些 出 错 不 打印 异常 堆栈 的 行为 ! 我 相信 ， 任 何 一 个 得 区 
于 异 音 堆栈 而 快速 定位 问题 的 程序 员 来 说 ,一定 对 这 人 句 话 深 有 体会 。 
所 以 ， 这 里 我 们 将 和 大 家 讨论 癌 线 程 池 讨 回 异 第 堆栈 的 方法 。 


一 种 最 简单 的 方法 ， 束 是 放弃 submit()， 改 用 execute()。 将 上 壕 的 
任务 提交 代码 改 成 : 


pools.execute(new DivTask(100,1)); 


或 者 你 使 用 下 面 的 方法 改造 你 的 submit(): 


Future re=pools.submit(new DivTask(100,i)); 


re.get(); 


上 面 两 种 方法 都 可 以 得 到 部 分 堆栈 信息 ， 如 下 所 示 : 


Exception in thread "nool-1-thread-1" 
java.lang.ArithmeticException: / by zero 
at geym.conc.ch3.trace.DivTask.run(DivTask. java:11) 
at 
java.util.concurrent.ThreadPoolExecutor.runwWorker(ThreadPoolExe 
cutor. java:1142) 
at 
java.util.concurrent.ThreadPoolExecutor$worker.run(ThreadPoolEx 
ecutor. java:617) 
at java.lang.Thread.run(Thread. java: 745) 
33.0 
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注意 了 ， 我 这 里 说 的 是 部 分 。 这 十 因 为 从 这 两 个 异常 堆栈 中 我 们 
只 能 知道 异常 是 在 哪里 抛 出 的 〈 这 里 是 DivTask 的 第 11 行 ) 。 但 是 我 们 
还 布 望 得 到 另外 一 个 更 重要 的 信息 ， 那 惑 是 这 个 任务 到 撒 是 在 哪里 拓 
交 的 ? 而 任务 的 具体 提交 位 置 已 被 线程 池 完 全 淹没 了 。 顺 着 堆栈 ， 
我 们 最 多 只 能 找到 线程 池 中 的 调度 流程 ， 而 这 对 于 我 们 几乎 是 没有 价 
值 的 。 


既然 这 样 ， 我 们 只 能 自己 动手 ， 丰 衣 足 食 啦 ! 为 了 今后 少 加 几 天 
H, ee 扩展 我 们 的 
ThreadPoolExecutor 线 程 池 ， 让 它 在 调度 任务 之 前 ， 先 你 存 一 下 提交 任 
务 线程 的 堆栈 信息 。 如 下 所 示 : 


01 public class TraceThreadPoolExecutor extends 


ThreadPoolExecutor { 


02 public TraceThreadPoolExecutor(int corePoolSize, int 
maximumPoolSize, 
03 long keepAliveTime, TimeUnit unit, BlockingQueue 


<Runnable> workQueue) { 
04 super(corePoolSize, maximumPoolSize, keepAliveTime, 


unit, workQueue); 


05 } 

06 

07 @Override 

08 public void execute(Runnable task) { 

09 super.execute(wrap(task, clientTrace(), 


Thread. currentThread() 


10 .getName())); 

11 } 

12 

13 @Override 

14 public Future<?> submit(Runnable task) { 

15 return super.submit(wrap(task, clientTrace(), 


Thread. currentThread() 


16 .getName())); 

17 } 

18 

19 private Exception clientTrace() { 

20 return new Exception("Client stack trace"); 


2i } 


22 
23 private Runnable wrap(final Runnable task, final 


Exception clientStack, 


24 String clientThreadName) { 
25 return new Runnable() { 

26 @Override 

27 public void run() { 

28 try { 

29 task.run(); 

30 } catch (Exception e) { 
31 clientStack.printStackTrace()j; 
32 throw e; 

33 } 

34 } 

35 3; 

36 } 

37 } 


FER IB IMS FE, wapp hik B2TSRIN— TH, BRE 
着 提交 任务 的 线程 的 堆栈 信息 。 该 方法 将 我 们 传 入 的 Runnable 任 务 进 
行 一 改 包 装 ， 使 之 能 处 理 异 营 信 息 。 当 任务 发 生 弄 彰 时 ， 这 个 异 和 会 
被 打印 。 


好 了 ， 现 在 可 以 使 用 我 们 的 新 成 员 (TraceThreadPoolExecutor) 来 
尝试 执行 这 上 段 代 码 了 : 


14 public static void main(String[] args) { 


15 ThreadPoolExecutor pools=new TraceThreadPoolExecutor (0, 


Integer .MAX_VALUE, 


16 OL, TimeUnit.SECONDS, 

17 new SynchronousQueue<Runnable>()); 
18 

19 ass 

20 * 错误 堆栈 中 可 以 看 到 是 在 哪里 提交 的 任务 

21 sy 

22 for(int i=0;i<5;i++){ 

23 pools.execute(new DivTask(100,i)); 
24 } 

25.5} 


执行 上 述 代码 ， 束 可 以 得 到 以 下 信息 : 


java.lang.Exception: Client stack trace 
at 
geym.conc.ch3.trace.TraceThreadPoolExecutor.clientTrace(TraceTh 
readPoolExecutor. java: 28) 
at 
geym.conc.ch3.trace.TraceThreadPoolExecutor.execute(TraceThread 
PoolExecutor.java:17) 
at geym.conc.ch3.trace.TraceMain.main(TraceMain. java: 23) 
Exception in thread "nool-1-thread-1" 
java.lang.ArithmeticException: / by zero 
at geym.conc.ch3.trace.DivTask.run(DivTask. java:11) 
at 


geym.conc.ch3.trace.TraceThreadPoolExecutor$1.run(TraceThreadPo 


olExecutor .java:37) 

at 
java.util.concurrent.ThreadPoolExecutor.runworker (ThreadPoolExe 
cutor.java:1142) 

at 
java.util.concurrent.ThreadPoolExecutor$worker.run(ThreadPoolEx 
ecutor.java:617) 

at java.lang.Thread.run(Thread. java: 745) 
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熟悉 的 异常 又 回来 了 ! 现在 ， 我 们 不 仅 可 以 得 到 异常 发 生 的 
Runnable 实 现 内 的 信息 ， 我 们 也 知道 了 这 个 任务 是 在 哪里 提交 的 。 如 
此 丰富 的 信息 ， 我 相信 可 以 帮助 我 们 瞬间 定位 问题 | 


3.2.9 “分 而 治之 : Fork/Join 框 架 


“分 而 治之 ”一 直 是 一 个 非常 有 效 地 处 理 大 量 数据 的 方法 。 著 名 的 
MapReduce 也 是 采取 了 分 而 治之 的 思想 。 人 简单 来 说 ， 残 是 如 果 你 要 处 
理 1000 个 数据 ， 但 是 你 并 不 具备 处 理 1000 个 数据 的 能 力 ， 那 么 你 可 以 
只 处 理 其 中 的 10 个 ， 然 后 ， 分 阶段 处 理 100 次 ， 将 100 次 的 结 采 进行 合 
成 ， 那 惑 是 最 终 想 要 的 对 原始 1000 个 数据 的 处 理 结果 。 


Fork 一 词 的 原始 含义 是 吃饭 用 的 又 子 ， 也 有 分 义 的 意思 。 在 Linux 
平台 中 ， 画 数 forkO 用 来 创建 子 进程 ， 使 得 系统 进程 可 以 多 一 个 执行 分 


文 。 在 Java 中 也 沿用 了 类 似 的 命名 方式 。 


而 join0 的 含义 在 之 前 的 章节 中 已 经 解释 过 ， 这 里 也 是 相同 的 意 
思 ， 表 示 等 待 。 也 就 是 使 用 forkO 后 系统 多 了 一 个 执行 分 支 (线程 ) ， 
所 以 需要 等 待 这 个 执行 分 文 执行 完毕 ， 才 有 可 能 得 到 最 终 的 结果 ， 
此 join0 就 表示 等 待 。 


在 实际 使 用 中 ， 如 有 果 肥 无 顾忌 地 使 用 fork() 开 启 线 程 进行 处 理 ， 那 
么 很 有 可 能 导致 系统 开局 过 多 的 线程 而 严重 影响 性 能 。 所 以 ， 在 JDK 
中 ， 给 出 了 一 个 ForkJoinPool 线 程 池 ， 对 于 fork() 方 法 并 不 急 着 开启 线 
程 ， 而 是 提交 给 ForkJoinPool 线 程 池 进 行 处 理 ， 以 节省 系统 资源 。 使 用 
Fork/Join 进 行 数据 处 理 时 的 总 体 结构 如 图 3.8 所 示 。 


> pert’ 


图 3.8 ”Fork/Join 执 行 逻 辑 


由 于 线程 池 的 优化 ， 提 区 的 任务 和 线程 数量 并 不 是 一 对 一 的 天 
系 。 在 绝 大 多 数 情况 下 ， 一 个 物理 线程 实际 上 是 需要 处 理 多 个 逻辑 任 
务 的。 因此 ， 每 个 线程 必然 需要 拥有 一 个 任务 队列 。 因 此 ， 在 实际 执 
行 过 程 中 ， 可 能 遇 到 这 么 一 种 情况 : 线程 A 已 经 把 自己 的 任务 都 执行 
完成 了 ， 而 线程 B 还 有 一 堆 任务 等 着 处 理 ， 此 时 ， 线 程 A 束 会 “帮助 ” 线 
程 B， 从 线程 B 的 任务 队列 中 拿 一 个 任务 过 来 处 理 ， 尽 可 能 地 达到 平 
衡 。 如 图 3.9 所 示 ， 显 示 了 这 种 互相 帮助 的 精神 。 一 个 值得 注意 的 地 方 
古 ， 当 线程 试图 帮助 别人 时 ， 总 是 从 任务 队列 的 抬 部 开始 拿 数 据 ， 而 
线程 试图 执行 目 己 的 任务 时 ， 则 是 从 相反 的 项 部 开始 拿 。 因 此 这 种 行 
为 也 十 分 有 利于 避免 数据 范 争 。 
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图 3.9 互相 帮助 的 线程 


下 面 我 们 来 看 一 下 ForkJoinPool 的 一 个 重要 的 接口 : 


public <T> ForkJoinTask<T> submit(ForkJoinTask<T> task) 


你 可 以 同 ForkJoinPool 线 程 池 提 交 一 个 ForkJoinTask 任 务 。 所 请 
ForkJoinTask 任务 就 是 文 持 fork0 分 解 以 及 join0 等 得 的 任务 。 
ForkJoinTask 有 两 个 重要 的 子 类 ，RecursiveAction 和 RecursiveTask。 它 
们 分 别 表示 没有 运 回 值 的 任务 和 可 以 携带 返回 值 的 任务 。 图 3.10 显 示 
了 这 两 个 类 的 作用 和 区 别 。 
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图 3.10 ” RecursiveAction 和 RecursiveTask 


下 面 我 们 人 简单 地 展示 Fork/Join 框 架 的 使 用 ， 这 里 用 来 计算 数列 求 
和 。 


01 public class CountTask extends RecursiveTask<Long>{ 


02 private static final int THRESHOLD = 10000; 
03 private long start; 
04 private long end; 


05 


06 public CountTask(long start,long end){ 


07 this.start=start; 

08 this.end=end; 

09 } 

10 

11 public Long compute(){ 

12 long sum=0; 

13 boolean canCompute = (end-start) <THRESHOLD; 
14 if (canCompute) { 

15 for(long i=start;i<=end;itt+){ 

16 sum +=1; 

17 } 

18 selse{ 

19 // 分 成 100 个 小 任务 

20 long step=(start+end)/100; 

21 ArrayList <CountTask> subTasks=new ArrayList< 


CountTask>(); 


22 long pos=start; 

23 for(int i=0;i<100;i++){ 

24 long lastOne=pos+step; 

25 if(lastOne>end)lastOne=end; 

26 CountTask subTask=new 


CountTask(pos, lastOne) ; 


27 post+=stepti,; 
28 subTasks.add(subTask); 
29 subTask.fork(); 


30 } 


31 for(CountTask t:subTasks){ 


32 sum+=t .join(); 

33 } 

34 } 

35 return sum; 

36 } 

37 

38 public static void main(String[]args){ 

39 ForkJoinPool forkJoinPool = new ForkJoinPool(); 

40 CountTask task = new CountTask(0, 200000L); 

41 ForkJoinTask<Long> result = 


forkJoinPool.submit(task); 


42 try{ 
43 long res = result.get(); 
44 System.out.printin("sum="+res); 
45 }catch(InterruptedException e){ 
46 e.printStackTrace(); 
47 }catch(ExecutionException e){ 
48 e.printStackTrace(); 
49 } 
50 } 
51 } 
由 于 计算 数列 的 和 必然 是 图 数 返 回 值 的 ， 因 此 选择 


ee E ， 建 立 ForkJoinPool 线 
程 池 。 在 第 40 行 ， 构 造 一 人 1 计算 1 到 200000 求 和 的 任务 。 在 第 41 行 将 任 
务 提交 给 线程 池 | 线程 池 会 返回 一 个 携 市 结果 的 任务 ， 通 过 get() 方 法 


可 以 得 到 最 终结 果 〈 第 43 行 ) 。 如 果 在 执行 get0) 方 法 时 ， 任 务 没 有 结 
束 ， 那 么 主线 程 吏 会 在 get(0 方 法 时 等 竺 。 


下 面 来 看 一 下 CountTask 的 实现 。 首 移 CountTask 继 承 目 
RecursiveTask， 可 以 携带 返回 值 ， 这 里 的 返回 值 类 型 设置 为 long。 第 2 
行 定 义 的 THRESHOLD 设 置 了 任务 分 解 的 规模 ， 也 束 是 如 果 需 要 求 和 
的 总 数 大 于 THRESHOLD 人 个， 那么 任务 束 需 要 再 次 分 解 ， 否 则 残 可 以 
直接 执行 。 这 个 判断 逻辑 在 第 14 行 有 体现 。 如 果 任 务 可 以 直接 执行 ， 
那么 直接 进行 求 和 ， 返 回 结果 。 否 则 ， 就 对 任务 再 次 分 解 。 每 次 分 解 
时 ， 简 单 地 将 原 有 任务 划分 成 100 个 等 规模 的 小 任务 ， 并 使 用 forkO 提 
交 子 任务 。 之 后 ， 等 待 所 有 的 子 任务 结束 ， 并 将 结果 再 次 求 和 (第 31 
~33{T) 。 


在 使 用 ForkJoin 时 需要 注意 ， 如 有 果 任 务 的 划分 层次 很 深 , 一直 得 
不 到 返回 ， 那 么 可 能 出 现 两 种 情况 : 第 一 ， 系 统 内 的 线程 数量 越 积 越 
多 ， 导 致 性 能 产 重 下 降 。 第 二 ， 函 数 的 调用 层次 变 得 很 深 ， 最 终 导致 
栈 盗 出。 不 同 版 本 的 JDK 内 部 实现 机 制 可 能 有 差异 ， 从 而 导致 其 表现 
不 同 。 


下 面 的 StackOverflowError 异 常 束 是 加 深 本 例 的 调用 层次 ， 在 JDK 
8 上 得 到 的 错误 。 


java.util.concurrent.ExecutionException: 
java. lang.StackOverflowError 
at 
java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1000) 
at geym.conc.ch3.fork.CountTask.main(CountTask.java:51) 


Caused by: java.lang.StackOverflowError 


此 外 ，ForkJoin 线 程 池 使 用 一 个 无 锁 的 栈 来 管理 至 闲 线程 。 如 采 
一 个 工作 线程 暂时 取 不 到 可 用 的 任务 ， 则 可 能 会 被 挂 起 ， 挂 起 的 线程 
将 会 被 讨 入 由 线程 池 维 护 的 栈 中 。 竺 将 来 有 任务 可 用 时 ， 再 从 栈 中 唤 
醒 这 些 线程 。 


33 ”不 要 重复 发 明 轮 子 : JDK 的 并 
发 容器 


除了 提供 诸如 同步 控制 ， 线 程 池 等 基本 工具 外 ， 为 了 提高 开发 人 
员 的 效率 ，JDK 还 为 大 家 准备 了 一 大 批 好 用 的 容 占 类 ， 可 以 大 大 减少 
开发 工作 量 。 大 家 应 该 都 昕 说 过 一 种 说 法 ， 所 请 程序 就 是 “算法 + 数据 
结构 ”， 这些 容 器 类 束 古 为 大 家 准备 好 的 线程 数据 结构 。 你 可 以 在 里 面 
找到 链表 、HashMap、 队 列 等 。 当 然 ， 它 们 都 十 线程 安全 的 。 


在 这 里 ， 我 也 打算 伦 一 些 篇 幅 为 大 家 介绍 一 下 这 些 工 具 类 。 这 些 
容 需 类 的 封装 都 是 非常 完善 并 且 “ 平 易 近 人 ”的 ， 也 束 是 说 只 要 你 有 那 
么 一 太太 的 编程 经 验 ， 束 可 以 非常 容易 地 使 用 这 些 容 右 。 因 此 ， 我 可 
能 会 化 更 多 的 时 间 来 分 析 这 些 工 具 的 具体 实现 ， 布 户 起 到 抛砖引玉 的 
作用 。 


ri 超 好 用 的 工具 类 : FARAH 


JDK 提 供 的 这 些 容 絮 大 部 分 在 java.util.concurrent 包 中 。 我 先 提纲 
者 领地 介绍 一 下 它们 ， 初 次 露脸 ， 大 家 只 需要 知道 他 们 的 作用 即 可 。 
有 关上 具体 的 实现 和 注意 事项 ， 在 后 面 我 会 慢 慢 道 来 。 


e ConcurrentHashMap: 这 是 一 个 高 效 的 并 发 HashMap“。 你 可 以 理 
解 为 一 个 线程 安全 的 HashMap。 


e CopyOnWriteArrayList : X ve — Ô List, M4 FAH æ A 

ArrayList 是 一 族 的 。 在 读 多 写 少 的 场合 ， 这 个 List 的 性 能 非常 

tf, mtf F Vector ° 

ConcurrentLinkedQueue: 高 效 的 并 发 队列 ， 使 用 链表 实现 。 可 

以 看 做 一 个 线程 安全 的 LinkedList 。 

BlockingQueue: 这 是 一 个 接口 ，JDK 内 部 通过 链表 、 数 组 等 方 

式 实现 了 这 个 接口 。 表 示 阻 蹇 队列 ， 非 常 适 合用 于 作为 数据 共 

享 的 通道 。 

e ConcurrentSkipListMap: 跳 表 的 实现 。 这 是 一 个 Map， 使 用 跳 
表 的 数据 结构 进行 快速 查找 。 


除了 以 上 并 发 包 中 的 专 有 数据 结构 外 ，java.util 下 的 Vector 是 线程 
安全 的 (虽然 性 能 和 和 上述 专用 工具 没 得 比 ) ， 另 外 Collections 工 具 类 
可 以 帮助 我 们 将 任意 集合 包装 成 线程 安全 的 集合 。 


3.3.2 ”线程 安全 的 HashMap 


在 之 前 的 章 广 中 ,已 经 给 大 家 展示 了 在 多 线程 环境 中 使 用 
HashMap 所 带 来 的 问题 。 那 如 果 需 要 一 个 线程 安全 的 HashMap 应 该 护 
ZL MVE? 一 种 可 行 的 方法 是 使 用 Collections.synchronizedMap0 方 法 包 
装 我 们 的 HashMap。 如 下 代码 ， 产 生 的 HashMap 束 是 线程 安全 的 : 


public static Map m=Collections.synchronizedMap(new HashMap()); 


Collections.SynchronizedMapO 会 生成 一 个 名 为 SynchronizedMap 的 
Map。 它 使 用 委托 ， 将 自己 所 有 Map 相 关 的 功能 交 给 传 入 的 HashMap 
实现 ， 而 自己 则 主要 负责 保证 线程 安全 。 


具体 参考 下 面 的 实现 ， 首 先 SynchronizedMap 内 包装 了 一 个 Map。 


private static class SynchronizedMap<kK,V> 
implements Map<K,V>, Serializable { 


private static final long serialVersionUID = 


1978198479659022715L; 

private final Map<K,V> m; // Backing Map 

final Object mutex; // Object on which to 
synchronize 


通过 mutex 实 现 对 这 个 m 的 互 扩 操作。 上 比如， 对 于 Map.get(0) 方 法 ， 
它 的 实现 如 下 : 


public V get(Object key) { 


synchronized (mutex) {return m.get(key);} 


而 其 他 所 有 相关 的 Map 探 作 都 会 使 用 这 个 mutex 进 行 同 步 。 从 而 实 
现 线程 安全 © 


这 个 包装 的 Map 可 以 满足 线程 安全 的 要 求 。 但 是 ， 它 在 多 线程 环 
境 中 的 性 能 表现 并 不 算 太 好 。 无 ; ， ee Be 都 需要 
获得 mutex 的 锁 ， 这 会 导致 所 有 对 Map 的 操作 全 部 进 IRA, Hel 
mutex 锁 可 用 。 如 有 果 并 发 级 别 不 高 ， 一 般 也 够 用 。 |， 
中 ， 我 们 也 有 必要 寻求 新 的 解决 方案 。 


一 个 更 加 专业 的 并 发 HashMap 是 ConcurrentHashMap。 它 位 于 
java.util.concurrent 包 内 。 它 专门 为 并 发 进行 了 性 能 优化 ， 因 此 ， 更 加 


适合 多 线程 的 场合 。 


有 关 ConcurrentHashMap 的 具体 实现 细节 ， 大 家 可 以 参考 “第 4 章 锁 
的 优化 及 注意 事项 ”一 章 。 我 们 将 在 那里 给 出 更 加 详细 的 实现 说 明 。 


3.3.3 ”有关 List 的 线程 安全 


队列 、 链 表 之 类 的 数据 结构 也 是 极其 党 用 的 ， 几 乎 所 有 的 应 用 程 
序 都 会 与 之 相关 。 在 Java 中 ，ArrayList 和 Vector 都 是 使 用 数组 作为 其 内 
部 实现 。 两 者 最 大 的 不 同 在 于 Vector 是 线程 安全 的 ， 而 ArrayList 不 是 。 
此 外 ，LinkedList 使 用 链表 的 数据 结构 实现 了 List。 但 是 很 不 笠 ， 
LinkedList 并 不 是 线程 安全 的 ， 不 过 参考 前 面 对 HashMap 的 包装 ， 在 这 
里 我 们 也 可 以 使 用 Collections.synchronizedListO) 方 法 来 包 厂 任意 List， 
如 下 所 示 : 


public static List<String> 1=Collections.synchronizedList (new 


LinkedList <String>()); 


此 时 生成 的 List 对 象 束 是 线程 安全 的 。 


3.3.4 ”高 效 读 写 的 队列 : 深度 剖析 
ConcurrentLinkedQueue 
队列 Queue 也 是 常用 的 数据 结构 之 一 。 在 JDK 中 提供 了 一 个 


ConcurrentLinkedQueue 类 用 来 实现 高 并 发 的 队列 。 从 名 字 可 以 看 到 ， 
这 个 队列 使 用 链表 作为 其 数据 结构 。 有 关 ConcurrentLinkedQueue 的 性 


能 测试 ， 大 家 可 以 目 行 尝试 。 这 里 限于 篇 幅 就 不 再 给 出 性 能 测试 的 代 
人 码 。 大 家 只 要 知道 ConcurrentLinkedQueue 应 该 算是 在 高 并 发 环境 中 性 
能 最 好 的 队列 就 可 以 了 。 它 之 所 有 能 有 很 好 的 性 能 ， 是 因为 其 内 部 复 
采 的 实现 。 


在 这 里 ， 我 更 加 愿意 花 一 些 篇 幅 来 简单 介绍 一 下 
ConcurrentLinkedQueue 的 具体 实现 细 市 。 不 过 在 深入 
ConcurrentLinkedQueue 之 前 ， 我 强烈 建议 大 家 和 驳 阅 读 一 下 第 4 章 ， 补 充 
一 下 有 关 无 锁 操 作 的 一 些 知识 。 


作为 一 个 链表 ， 目 然 需 要 定义 有 关 链 表 内 的 和 点 ， 在 
ConcurrentLinkedQueue 中 ， 定 义 的 节点 Node 核 心 如 下 : 


private static class Node<E> { 
volatile E item; 


volatile Node<E> next; 


其 中 item 是 用 来 表示 目标 元 素 的 。 比 如 ， 当 列表 中 存放 String 时 
item 就 是 String 类 型 。 字 上 段 next 表 示 当 前 Node 的 下 一 个 元 素 ， 这 样 每 个 
Node 就 能 环 环 相 扣 ， 串 在 一 起 了 。 如 图 3.11 所 示 ， 显 示 了 了 
ConcurrentLinkedQueue 的 基本 结构 。 


Node 
offer() item 
poll() next 


图 3.11 ”ConcurrentLinkedQueue 基 本 结构 


对 Node 进 行 操作 时 ， 使 用 了 CAS 操 作 。 


boolean casItem(E cmp, E val) { 
return UNSAFE.compareAndSwapObject(this, itemOffset, cmp, 
val); 


} 


void lazySetNext(Node<E> val) { 


UNSAFE. putOrderedObject(this, nextOffset, val); 


boolean casNext(Node<E> cmp, Node<E> val) { 
return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, 
val); 


} 


方法 casItem() 表 示 设 置 当 前 Node 的 item 值 。 它 需要 两 个 参数 ， 第 
一 个 参数 为 期 望 值 ， 第 二 个 参数 为 设置 目标 值 。 当 当前 值 等 于 cmp 期 
望 值 时 ， 职 会 将 目标 设置 为 val。 同 样 casItem0) 方 法 也 是 类 似 的 ， 但 是 
它 是 用 来 设置 next 字 段 ， 而 不 是 item 字 段 。 


ConcurrentLinkedQueue 内 部 有 两 个 重要 的 字段 ，head 和 tail， 分 别 
表示 链表 的 头 部 和 尾部 ， 它 们 都 是 Node 类 型 。 对 于 head 来 说 ， 它 永远 
不 会 为 null， 并 且 通 过 head 以 及 succ0 后 继 方 法 一 定 能 完整 地 遍历 整 个 
链表 。 对 于 tail 来 说 ， 它 目 然 应 该 表示 队列 的 末尾 。 


但 ConcurrentLinkedQueue 的 内 部 实现 非常 复 杀 ， 它 允许 在 运行 时 
能 表 处 于 多 个 不 同 的 状态 。 以 tait 为 例 ， 一 般 来 说 ， 我 们 期 望 tail 总 是 


为 链表 的 末尾 ， 但 实际 上 ，tail 的 更 新 并 不 是 及 时 的 ， 而 是 可 能 会 产生 
拖延 现象 。 如 图 3.12 所 示 ， 显 示 了 插入 时 ，tail 的 更 狐 情 况 ， 可 以 看 到 
tail 的 更 狐 会 产生 洲 后 ， 并 且 每 次 更 狐 会 跳跃 两 个 元 素 。 
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图 3.12 插入 节点 时 tail 的 更 新 


可 以 看 到 tail 并 不 总 是 在 更 新 。 下 面 就 是 ConcurrentLinkedQueue 中 
向 队列 中 添加 元 素 的 offer0 方 法 〈 本 届 中 使 用 JDK 7u40 的 代码 ， 不 同 
版 本 的 代码 可 能 存在 差异 ) : 


01 public boolean offer(E e) { 


02 checkNotNull(e); 

03 final Node<E> newNode = new Node<E> (e); 
04 

05 for (Node<E> t = tail, p= t;;) { 


06 Node<E> q = p.next; 


07 if (q == null) { 


08 // p 是 最 后 一 个 节点 

09 if (p.casNext(null, newNode)) { 

10 // 每 2 次 ， 更 新 一 下 tail 

11 if (p l= ©) 

12 casTail(t, newNode); 

13 return true; 

14 } 

15 //CAS 竞 争 失败 ， 再 次 尝试 

16 } 

17 else if (p == q) 

18 //jazB ET, Mhead FiA ° 

19 // 但 如 果 tail 被 修改 ， 则 使 用 tail (因为 可 能 被 修改 正确 了 ) 
20 p= (t != (t = tail)) ? t : head; 

21 else 

22 A 人 设 后 

23 p=(p!=t & t != (t = tail)) ? t : q; 
24 } 

25 } 


首先 值得 注意 的 是 ， 这 个 方法 没有 任何 锁 操 作 。 线 程 安全 完全 由 
CAS 探 作 和 队列 的 算法 来 保证 。 整 个 方法 的 核心 是 for 循 环 ， 这 个 循环 
没有 出 口 ， 直 到 党 试 成 功 ， 这 也 符合 CAS 操 作 的 流程 。 当 第 一 次 加 入 
元 素 时 ， 由 于 队列 为 空 ， 因 此 p.next 为 null。 程 序 进 入 第 8 行 。 并 将 p 的 
next 点 赋值 为 newNode， 也 惑 是 将 新 的 元 素 加 入 到 队列 中 。 此 时 p==t 
成 立 ， 因 此 不 会 执行 第 12 行 的 代码 更 新 tail 末 尾 。 如 果 casNext() 成 功 ， 


程序 直接 返回 ， 如 末 失 败 ， 则 再 进行 一 次 循环 答 试 ， 直 到 成 功 。 
此 ， 增 加 一 个 元 素 后 ，tail 并 不 会 被 更 新 。 


当 程序 试图 增加 第 2 个 元 素 时 ， 由 于 t 还 在 head 的 位 置 上 ， 因 此 
p.next 指 向 实际 的 第 一 个 元 素 ， 因 此 第 6 行 的 g!=null， 这 表示 g 不 是 最 后 
的 节点 。 由 于 往 队 列 中 增加 元 素 需 要 最 后 一 个 节点 的 位 置 ， 因 此 ， 循 
环 开始 查找 最 后 一 个 节点 。 于 是 ， 程 序 会 进入 第 23 行 ， 获 得 最 后 一 个 
广 点 。 此 时 ，p 实 际 上 是 指 问 链表 中 的 第 一 个 元 素 ， 而 它 的 next 为 
null， 故 在 第 2 个 循环 时 ， 进 入 第 8 行 。p 更 新 自己 的 next， 让 它 指 问 新 
加 入 的 节点 。 如 果 成 功 ， 由 于 此 时 p!=t 成 功 ， 则 会 更 新 t 所 在 位 置 ， 将 t 
移动 到 链表 最 后 。 


在 第 17 行 ， 处 理 了 p==q 的 情况 。 这 种 情况 是 由 于 过 到 了 哨兵 
(sentinel) 节点 导致 的 。 所 请 哨兵 市 点 ， 就 是 next 指 同 目 己 的 节点 。 
这 种 三 点 在 队列 中 的 存在 价值 不 大 ， 主 要 表示 要 删除 的 节点 ， 或 者 空 
廊 点 。 当 中 到 哨兵 节点 上 时， 由 于 无 法 通过 next 取 得 后 续 的 节点 ， 因 此 
很 可 能 直接 返回 head， 期 望 通过 从 链表 头 部 开始 遇 历 ， 进 一 步 查 找到 
链表 末尾 。 但 一 旦 发 生 在 执行 过 程 中 ，tail 被 其 他 线程 修改 的 情况 ， 则 
进行 一 次 “打赌 >， 使 用 新 的 tail 作 为 链表 末尾 〈 这 样 就 避免 了 重新 查找 
tail 的 开销 ) 。 


如 果 大 家 对 Java 不 是 特别 熟悉 ， 可 能 会 对 类 似 下 面 的 代码 产生 疑 
Rk (第 20 行 ): 


p= (t != (t = tail)) ? t : head; 


这 名 代码 虽然 只 有 短 短 一 行 ， 但 是 包含 的 信息 比较 多 。 首 
先 “!=” 并 不 是 原子 操作 ， 它 是 可 以 被 中 断 的 。 也 就 是 说 ， 在 执 


行 “!=” 是 ， 程 序 会 先 取 得 的 值 ， 再 执行 t=tail， 并 取得 新 的 t 的 值 。 然 后 
比较 这 两 个 值 是 否 相 等 。 在 单线 程 时 ，t!=t 这 种 语句 显然 不 会 成 立 。 但 
征 在 并 发 环境 中 ， 有 可 能 在 获得 左边 的 t 值 后 ， 右 边 的 t 值 被 其 他 线程 
修改 。 这 样 ，t!=t 束 可 能 成 立 。 这 里 束 古 这 种 情况 。 如 末 在 比较 过 程 
中 ，tail 被 其 他 线程 修改 ， 当 它 再 次 赋值 给 t 时 ， 束 会 导致 等 式 左边 的 t 
和 右边 的 t 不 同 。 如 有 果 两 个 t 不 相同 ， 表 示 tail 在 中 途 被 其 他 线程 党 改 。 
这 时 ， 我 们 束 可 以 用 新 的 tail 作 为 链表 末尾 ， 也 就 是 这 里 等 式 右边 的 
t。 但 如 果 tail 没 有 被 修改 ， 则 返回 head， 要 求 从 头 部 开始 ， 重 新 查找 尾 
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作为 简化 问题 ， 我 们 考察 t!=t 的 字 节 码 (注意 这 里 假设 t 为 静态 整 


WAR) 


11: getstatic #10 // Field t:I 
14: getstatic #10 // Field t:I 
17: if_icmpeq 24 


可 以 看 到 ， 在 字 节 码 层面 ，t 被 先后 取 了 两 次 ， 在 多 线程 环境 下 ， 
我 们 目 然 无 法 保证 两 次 对 t 的 取 值 会 古 相 同 的 ， 如 图 3.13 所 示 ， 显 示 了 
这 种 情况 。 
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图 3.13 tl=( 成 立 的 情况 


下 面 我 们 来 看 一 下 哨兵 节点 是 如 何 产生 的 : 


ConcurrentLinkedQueue< String> d=new ConcurrentLinkedQueue < 


String> (); 
q.add("1"); 
q.poll(); 


EARR T, ENINA ° RAITEEN F: 


01 public E poll() { 


restartFromHead: 
LOW (r) 4 
for (Node<E> h = head, p = h, q;;) { 


E item = p.item; 
if (item != null && p.casItem(item, null)) { 
if (p l= n) 
updateHead(h, ((q = p.next) != null) ? q 


09 return item; 

10 } 

11 else if ((q = p.next) == null) { 
12 updateHead(h, p); 

13 return null; 

14 } 

15 else if (p == q) 

16 continue restartFromHead; 
17 else 

18 p= q, 

19 } 

20 } 

21 } 


由 于 队列 中 只 有 一 个 元 素 ， 根 据 前 文 的 描述 ， 此 时 tail 并 没有 更 
新 ， 而 是 指向 和 head 相 同 的 位 置 。 而 此 时 ，head 本 喘 的 item 域 为 null， 
其 next 为 列表 第 一 个 元 素 。 故 在 第 一 个 循环 中 ， 代 码 直接 进入 第 18 
行 ， 将 p 赋 值 为 9， 而 q 就 是 p.next， 也 是 当前 列表 中 的 第 一 个 元 素 。 接 
着 ， 在 第 2 轮 循环 中 ，p.item 显 然 不 为 null (为 字符 串 1) 。 因 此 ， 代 码 
应 该 可 以 顺利 进入 第 7 行 (如 果 CAS 操 作成 功 ) 。 进 入 第 7 行 ， 也 意味 
着 p 的 item 域 被 设置 为 null (因为 这 是 弹出 元 素 ， 自 然 需要 删除 ) 。 同 
时 ， 此 时 p 和 h 是 不 相等 的 (因为 p 已 经 指向 原 有 的 第 一 个 元 素 了 ) 。 故 
执行 了 第 8 行 的 updateHead() 操 作 ， 其 实现 如 下 : 


final void updateHead(Node<E> h, Node<E> p) { 


if (h != p && casHead(h, p)) 


h.lazySetNext(h); 


可 以 看 到 ， 在 updateHead 中 ， 就 将 p 作 为 新 的 链表 头 部 (通过 
casHead) <2) ， 而 原 有 的 head 就 被 设置 为 哨兵 (通过 lazySetNext() 实 
现 ) 。 


这 样 一 个 哨兵 市 点 束 产 生 了 ， 而 由 于 此 时 原 有 的 head 头 部 和 tail 实 
际 上 是 同一 个 元 素 。 因 此 ， 再 次 offer0 播 入 元 素 时 ， 就 会 遇 到 这 个 
tail， 也 就 是 哨兵 。 这 就 是 offer0 代 码 中 ， 第 17 行 的 判断 的 意义 。 


通过 这 些 说 明 ， 大 家 应 该 可 以 明显 感觉 到 ， 不 使 用 锁 而 单纯 地 使 
用 CAS 操 作 会 要 求 在 应 用 层面 保证 线程 安全 ， 并 处 理 一 些 可 能 存在 的 
不 一 致 问题 ， 大 大 增加 了 程序 设计 和 实现 的 难度 。 但 是 它 训 来 的 好 处 
忠 古 可 以 得 到 性 能 的 飞速 提升 。 因 此 ， 在 有 些 场合 也 十 值 得 的 。 


3.3.5 ”高 效 读 取 : 不 变 模式 下 的 
CopyOnWriteArrayList 


在 很 多 应 用 场景 中 ， 读 操作 可 能 会 远 远大 于 写 操作 。 比 如 ， 有 些 
系统 级 别 的 信息 ， 往 往 只 需要 加 载 或 者 修改 很 少 的 次 数 ， 但 是 会 被 系 
统 内 所 有 模块 频繁 的 访问 。 对 于 这 种 场景 ， 我 们 最 布 望 看 到 的 束 是 读 
操作 可 以 尽 可 能 地 快 ， 而 写 即 使 慢 一 些 也 没有 太 大 关系 。 


由 于 读 操 作 根 本 不 会 修改 原 有 的 数据 ， 因 此 对 于 每 次 读 取 都 进行 
加 锁 其 实 是 一 种 资源 浪费 。 我 们 应 该 允许 多 个 线程 同时 访问 List 的 内 
部 数据 ， 毕 竟 读 取 操 作 走 安全 的 。 根 据 读 写 锁 的 思想 ， 读 锁 和 读 锁 之 


间 确 实 也 不 冲突 。 但 是 ， 读 操作 会 受到 写 操作 的 阻碍 ， 当 写 发 生 时 ， 
读 融 必 须 等 待 ， 否 则 可 能 读 到 不 一 致 的 数据 。 同 理 ， 如 果 读 操作 正在 
进行 ， 程 序 也 不 能 进行 写 入 。 


为 了 将 读 取 的 性 能 发 挥 到 极致 ，JDK 中 提供 了 
CopyOnWriteArrayList 类 。 对 它 来 说 ， 读 取 是 完全 不 用 加 锁 的 ， 并 且 更 
好 的 消息 是 : 写 入 也 不 会 阻塞 读 取 操 作 。 只 有 写 入 和 写 入 之 间 需 要 进 
行 同 步 等 待 。 这 样 一 来 ， 读 操作 的 性 能 就 会 大 幅度 提升 。 那 它 是 怎么 
做 的 呢 ? 


从 这 个 类 的 名 字 我 们 可 以 看 到 ， 所 谓 CopyOnWrite 就 是 在 写 入 操 
作 时 ， 进 行 一 次 自我 复制 。 换 句 话说 ， 当 这 个 List 需 要 修改 时 ， 我 并 
不 修改 原 有 的 内 容 〈 这 对 于 保证 当前 在 读 线程 的 数据 一 致 性 非常 重 
要 ) ， 而 是 对 原 有 的 数据 进行 一 次 复制 ， 将 修改 的 内 容 写 入 副本 中 。 
写 完 之 后 ， 再 将 修改 完 的 副本 替换 原来 的 数据 。 这 样 就 可 以 保证 写 操 
作 不 会 影响 读 了 。 


下 面 的 代码 展示 了 有 关 读 取 的 实现 ; 


private volatile transient Object[] array; 
public E get(int index) { 
return get(getArray(), index); 
i 
final Object[] getArray() { 
return array; 


} 
private E get(Object[] a, int index) { 


return (E) a[index]; 


需要 注意 的 是 : MARRIES EAR ee aE, FR 
内 部 数组 array 不 会 发 生 修改 ， 只 会 被 男 外 一 个 array 蔡 换 ， 因 此 可 以 保 
证 数据 安全 。 大 家 也 可 以 参考 “5.2 不 变 模 式 ” 一 站 ， 相 信 可 以 有 更 深 的 


认识 


和 简单 的 读 取 相 比 ， 写 入 操作 束 有 些 厅 烦 了 : 


01 public boolean add(E e) { 


02 final ReentrantLock lock = this.lock; 
03 lock.lock(); 

04 try { 

05 Object[] elements = getArray(); 
06 int len = elements.length; 

07 Object[] newElements = Arrays.copyOf(elements, len + 
1); 

08 newElements[len] = e; 

09 setArray(newElements); 

10 return true; 

11 } finally { 

12 lock.unlock(); 

13 } 

14 } 


目 先 ， 写 入 操作 使 用 锁 ， 当 然 这 个 锁 仅 限于 控制 写 - 写 的 情况 。 其 
重点 在 于 第 7 行 代码 ， 进 行 了 内 部 元 素 的 完整 复制 。 因 此 ， 会 生成 一 个 


新 的 数组 newElements。 然 后 ， 将 新 的 元 素 加 入 newElements。 接 着 , 
在 第 9 行 ， 使 用 新 的 数组 蔡 换 老 的 数组 ， 修 改 就 完成 了 。 上 整个 过 程 不 会 
影响 读 取 ， 并 且 修 改 完 后 ， 读 取 线 程 可 以 立即 “察觉 ?到 这 个 修改 (A 


= 


为 array 变 量 是 volatile 类 型 ) 。 


3.3.6 ”数据 共享 通道 : BlockingQueue 


前 文中 ， 我 们 已 经 提 到 了 ConcurrentLinkedQueue 作 为 高 性 能 的 队 
列 。 对 于 并 发 程序 而 言 ， 高 性 能 自然 是 一 个 我 们 需要 追求 的 目标 。 但 
多 线程 的 开发 模式 还 会 引入 一 个 问题 ， 那 惑 是 如 何 进 行 多 个 线程 间 的 
数据 共享 呢 ? 比 如 ， 线 程 A 希 望 给 线程 B 发 一 个 消息 ， 用 什么 方式 告知 
线程 B 是 比较 合理 的 呢 ? 


一 般 来 说 ， 我 们 总 是 希望 整个 系统 是 松散 耦合 的 。 比 如 ， 你 所 在 
小 区 的 物业 希望 可 以 得 到 一 些 业 主 的 意见 ， 设 立 了 一 个 意见 箱 ， 如 果 
对 物业 有 任何 要 求 和 或 者 意见 都 可 以 投 到 意见 箱 里 。 这 时 ， 作 为 业主 
的 你 并 不 需要 直接 找到 物业 相关 的 领导 表达 你 的 意见 。 实 际 上 ， 物 业 
的 工作 人 员 也 可 能 经 党 发 生变 动 ， 直 接 找 工 作 人 员 未 必 有 征 一 件 方便 的 
事情 。 而 你 投递 到 意见 箱 的 意见 总 是 会 被 物业 的 工作 人 员 看 到 ， 不 管 
征 否 发 生 了 人 员 的 变动 。 这 样 ， 你 束 可 以 很 容易 地 表达 目 己 的 诉求 
了 。 你 既 不 需要 直接 和 他 们 对 话 ， 又 可 以 轻松 提出 自己 的 建议 (这 里 
假定 我 们 物业 公司 的 员工 都 是 尽心 尽责 的 好 员工 ) 。 


将 这 个 模式 映射 到 我 们 程序 中 。 束 是 说 我 们 既 和 希望 线程 A 能 够 通 
知 线程 B， 又 希望 线程 A 不 知道 线程 B 的 存在 。 这 样 ， 如 采 将 来 进行 重 
构 或 者 升级 ， 我 们 完全 可 以 不 修改 线程 A， 而 直接 把 线程 B 升 级 为 线程 


C， 保 证 系统 的 平滑 过 渡 。 而 这 中 间 的 “意见 箱 ” 束 可 以 使 用 
BlockingQueue 来 实现 。 


与 之 前 提 到 的 ConcurrentLinkedQueue 或 者 CopyOnWriteArrayList 不 
同 ，BlockingQueue 是 一 个 接口 ， 并 非 一 个 具体 的 实现 。 它 的 主要 实现 
有 下 面 一 些 ， 如 图 3.14 所 示 。 
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“a ckhingQueue<E> - java. util. concurrent 
ArrayBlockingQueue<E> - java. util. concurrent 

Qs DelayedWorkQueue - java. util. concurrent. ScheduledThr: 
DelayQueue<E> - java. util. concurrent 
LinkedBlockingQueue<E> - java util. concurrent 
PriorityBlockingQueue<E> - java. util. concurrent 
SynchronousQueue<E> - java. util. concurrent 
BlockingDeque<E> - java.util. concurrent 
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图 3-14 ”BlockingQueue 的 主要 实现 


这 里 我 们 主要 介绍 ArrayBlockingQueue 和 LinkedBlockingQueue 。 
从 名 字 应 该 可 以 得 知 ，ArrayBlockingQueue 是 基于 数组 实现 的 ， 而 
LinkedBlockingQueue 基 于 链表 。 也 正 因为 如 此 ，ArrayBlockingQueue 
更 适合 做 有 界 队 列 ， 因 为 队列 中 可 容纳 的 最 大 元 素 需 要 在 队列 创建 时 
指定 (毕竟 数组 的 动态 扩展 不 太 方便 ) 。 而 LinkedBlockingQueue 适 合 
做 无 弄 队 列 ， 或 者 那些 边界 值 非常 大 的 队列 ， 因 为 其 内 部 元 素 可 以 动 
态 增 加 ， 它 不 会 因为 初 值 容量 很 大 ， 而 一 口气 吃 掉 你 一 大 半 的 内 存 。 


而 BlockingQueue 之 所 有 适合 作为 数据 共享 的 通道 ， 其 关键 还 在 于 
Blocking 上 。Blocking 是 阻塞 的 意思 ， 当 服务 线程 (服务 线程 指 不 断 获 
取 队 列 中 的 消息 ， 进 行 处 理 的 线程 ) 处 理 完 成 队列 中 所 有 的 消息 后 ， 
它 如 何 知道 下 一 条 消息 何 时 到 来 呢 ? 


一 种 最 傻瓜 化 的 做 法 是 让 这 个 线程 按照 一 定 的 时 间 间 隔 不 停 地 循 
环 和 监控 这 个 队列 。 这 是 可 行 的 一 种 方案 , 但 显然 造成 了 不 必要 的 资 
源 浪 费 ， 而 循环 周期 也 难以 确定 。 而 BlockingQueue 很 好 地 解决 了 这 个 
问题 。 它 会 让 服务 线程 在 队列 为 空 时 ， 进 行 等 每 ， 当 有 新 的 消 轧 进入 
队列 后 ， 上 自动 将 线程 唤醒 ， 如 图 3.15 所 示 。 那 它 是 如 何 实现 的 呢 ? 我 
们 以 ArrayBlockingQueue 为 例 ， 来 一 探究 竟 © 
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图 3.15 “BlockingQueue 的 工作 模式 


ArrayBlockingQueue 的 内 部 元 素 都 放置 在 一 个 对 象 数 组 中 : 


final Object[] items; 


向 队列 中 压 入 元 素 可 以 使 用 offer0 方 法 和 put0 方 法 。 对 于 offer0) 方 
法 ， 如 果 当 前 队列 已 经 满 了 ， 它 就 会 立即 返回 false。 如 果 没 有 满 ， 则 
执行 正常 的 入 队 操作 。 所 以 ， 我 们 不 讨论 这 个 方法 。 现 在 ， 我 们 需要 
关注 的 是 put0 方 法 。put(0) 方 法 也 是 将 元 素 压 入 队列 末尾 。 但 如 果 队 列 
满 了 ， 它 会 一 直 等 每 ， 直 到 队列 中 有 空 闪 的 位 置 。 


从 队列 中 弹出 元 素 可 以 使 用 poll0 方 法 和 take0 方 法 。 它 们 都 从 队 
列 的 头 部 获得 一 个 元 素 。 不 同 之 处 在 于 : 如 果 队 列 为 空 poll0 方 法 直接 
返回 nul， 而 take0 方 法 会 等 待 ， 直 到 队列 内 有 可 用 元 素 。 


因此 ，put0 方 法 和 take0) 方 法 才 是 体现 Blocking 的 关键。 为 了 做 好 
等 每 和 通知 两 件 事 ， 在 ArrayBlockingQueue 内 部 定义 了 以 下 一 些 字 


By: 


final ReentrantLock lock; 
private final Condition notEmpty; 


private final Condition notFull; 


当 执 行 take0 操 作 时 ， 如 果 队列 为 空 ， 则 让 当前 线程 等 待 在 
notEmpty 上 。 新 元 素 入 队 时 ， 则 进行 一 次 notEmpty 上 的 通知 。 


下 面 的 代码 显示 了 take() 的 过 程 : 


01 public E take() throws InterruptedException { 


02 final ReentrantLock lock = this.lock; 
03 lock.lockInterruptibly(); 

04 try { 

05 while (count == 0) 


06 notEmpty.await(); 


07 return extract(); 


08 } finally { 

09 lock.unlock(); 
10 } 

11 } 
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程 会 得 到 一 个 通知 。 下 面 是 元 素 入 队 时 的 一 段 代 码 : 


1 private void insert(E x) { 

2 items[putIndex] = x; 

3 putIndex = inc(putIndex); 
4 ++count; 

5 notEmpty.signal(); 

6 } 


注意 第 5 行 代 码 ， 当 新 元 素 进入 队列 后 ， 需 要 通知 等 待 在 notEmpty 
上 的 线程 ， 让 他 们 继续 工作 。 


同 理 ， 对 于 put0 操 作 也 是 一 样 的 ， 当 队列 满 时 ， 需 要 让 压 入 线程 
等 每 ， 如 下 面 第 7 行 。 


01 public void put(E e) throws InterruptedException { 


02 checkNotNull(e); 

03 final ReentrantLock lock = this.lock; 
04 lock. lockInterruptibly(); 

05 CRYS 


06 while (count == items.length) 


07 notFull.await(); 


08 insert(e); 

09 } finally { 

10 lock.unlock(); 
11 } 

i 人 2 


当 有 元 素 从 队列 中 被 挪 走 ， 队 列 中 出 现 空位 时 ， 目 然 也 需要 通知 
等 竺 入 队 的 线程 : 


1 private E extract() { 

2 final Object[] items = this.items; 

3 E x = this.<E>cast(items[takeIndex]); 
4 items[takeIndex] = null; 

5 takeIndex = inc(takeIndex); 

6 --count; 

7 notFull.signal(); 

8 return x; 

9 } 


上 述 代 码 表示 从 队列 中 拿 走 一 个 元 素 。 当 有 空 几 位 置 时 ， 在 第 7 
行 ， 通 知 等 每 入 队 的 线程 。 


BlockingQueue 的 使 用 非常 普遍 。 在 后 续 的 “5.3 生 产 者 消费 考 ” 一 市 
中 ， 我 们 还 会 看 到 他 们 的 号 影 。 在 那里 ， 我 们 可 以 更 清楚 地 看 到 如 何 
使 用 BlockingQueue 解 耘 生产 者 和 消费 者 。 


3.3.7 随机 数据 结构 : 跳 表 
(SkipList) 


在 JDK 的 并 发 包 中 ， 除 了 常用 的 哈 希 表 外 ， 还 实现 了 一 种 有 趣 的 
数据 结构 一 一 跳 表 。 跳 表 是 一 种 可 以 用 来 快速 查找 的 数据 结构 ， 有 点 
类 似 于 平衡 树 。 它 们 都 可 以 对 元 素 进 行 快速 的 查找 。 但 一 个 重要 的 区 
别 是 : 对 平衡 树 的 插入 和 删除 往往 很 可 能 导致 平衡 树 进行 一 次 全 局 的 
调整 。 而 对 跳 表 的 插入 和 删除 只 需要 对 整个 数据 结构 的 局 部 进行 操作 
即 可 。 这 样 遍 来 的 好 处 是 : 在 高 并 发 的 情况 下 ， 你 会 需要 一 个 全 局 锁 
来 保证 整个 平衡 树 的 线程 安全 。 而 对 于 跳 表 ， 你 只 需要 部 分 锁 即 可 。 
这 样 ， 在 高 并 发 环境 下 ， 你 就 可 以 拥有 更 好 的 性 能 。 而 就 查询 的 性 能 
而 言 ， 跳 表 的 时 间 复 杂 度 也 是 O(log n)。 所 以 在 并 发 数据 结构 中 ，JDK 
使 用 跳 表 来 实现 一 个 Map 。 


跳 表 的 男 外 一 个 特点 十 随 机 算法 。 跳 表 的 本 质 是 同时 维护 了 多 个 
链表 ， 并 且 链 表 是 分 层 的 ， 如 图 3.16 所 示 。 
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图 3.16 ” 跳 表 结构 示意 


最 低层 的 链表 维护 了 跳 表 内 所 有 的 元 素 ， 每 上 面 一 层 链表 都 是 下 
面 一 层 的 子 集 ， 一 个 元 素 插 入 哪些 层 是 完全 随机 的 。 因 此 ， 如 果 你 运 


气 不 好 的 话 ， 你 可 能 会 得 到 一 个 性 能 很 糟 糙 的 结构 。 但 是 在 实际 工作 
中 ， 它 的 表现 是 非常 好 的 。 


踏 表 内 的 所 有 链表 的 元 素 都 是 排序 的 。 碍 找 时 ， 可 以 从 顶级 链表 
开始 找 。 一 旦 发 现 被 查找 的 元 素 大 于 当前 链表 中 的 取 值 ， 束 会 转 入 下 
一 层 链表 继续 找 。 这 也 就 是 说 在 查找 过 程 中 ， 搜 索 是 跳 路 式 的 ， 如 图 
3.17 所 示 ， 在 跳 表 中 查找 元 素 7。 查找 从 顶层 的 头 部 索引 市 点 开始 。 由 
于 顶层 的 元 素 最 少 ， 因 此 ， 可 以 快速 跳 路 那 些小 于 7 的 元 素 。 很 快 ， 查 
找 过 程 束 能 到 元 素 6。 由 于 在 第 2 屋 ， 元 素 8 大 于 7， 故 肯定 无 法 在 第 2 层 
找到 元 素 7， 故 直接 进入 底层 (包含 所 有 元 素 ) MAER, HARRI 
可 以 根据 元 素 6 搜 索 到 元 素 7。 整 个 过 程 ， 要 比 一 般 链表 从 元 素 1 开 始 逐 
个 搜索 快 很 多 。 
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图 3.17 ” 跳 表 的 查找 过 程 


因此 ， 很 显然 ， 跳 表 是 一 种 使 用 空间 换 时 间 的 算法 。 


使 用 跳 表 实现 Map 和 使 用 哈 布 算法 实现 Map 的 另外 一 个 不 同 之 处 
E: 哈 希 并 不 会 保存 元 素 的 顺序 ， 而 跳 表 内 所 有 的 元 素 都 是 排序 的 。 
因此 在 对 跳 表 进行 遍历 时 ， 你 会 得 到 一 个 有 序 的 结 有 末 。 所 以 ， 如 采 你 
的 应 用 需要 有 序 性 ， 那 么 跳 表 殉 是 你 不 二 的 选择 。 


实现 这 一 数据 结构 的 类 是 ConcurrentSkipListMap。 下 面 展示 了 跳 
表 的 简单 使 用 : 


Map< Integer, Integer> map=new ConcurrentSkipListMap< Integer, 
Integer> (); 
for(int i=0;i<30;i++){ 
map.put(i,i); 
} 
for(Map.Entry<Integer, Integer> entry:map.entrySet()){ 


System.out.println(entry.getKey()); 


和 HashMap 不 同 ， 对 跳 表 的 过 历 输出 是 有 序 的 。 


跳 表 的 内 部 实现 有 几 个 关键 的 数据 结构 组 成 。 首 先是 Node， 一 个 
Node 就 是 表示 一 个 节点 ， 里 面 含 有 两 个 重要 的 元 素 key 和 value (就 是 
Map 的 key 和 value) 。 每 个 Node 还 会 指 问 下 一 个 Node， 因 此 还 有 一 个 
元 素 next ° 


static final class Node<K,V> { 
final K key; 
volatile Object value; 


volatile Node<K,V> next; 


对 Node 的 所 有 操作 ， 使 用 的 CAS 方 法 : 


boolean casValue(Object cmp, Object val) { 
return UNSAFE.compareAndSwapObject(this, valueOffset, cmp, 


val); 


boolean casNext(Node<K,V> cmp, Node<K,V> val) { 


return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, 


val); 


t 


方法 casValue0 用 来 设置 value 的 值 ， 相 对 的 casNextO 用 来 设置 next 
的 字段 。 


另外 一 个 重要 的 数据 结构 是 Imdex。 顾 名 思 义 ， 这 个 表示 索引 。 
内 部 包装 了 Node， 同 时 增加 了 回 下 的 引用 和 同 右 的 引用 。 


static class Index<K,V> { 
final Node<K,V> node; 
final Index<K,V> down; 


volatile Index<K,V> right; 


整个 跳 表 就 是 根据 Index 进 行 全 网 的 组 织 的 。 


此 外 ， 对 于 每 一 层 的 表 头 ， 还 需要 记录 当前 处 于 哪 一 层 。 为 此 ， 
还 需 ee 结构 ， 表 示 链 表 头 部 的 第 一 个 
Index。 它 继承 自 Index。 


static final class HeadIndex<K,V> extends Index<K,V> { 
final int level; 
HeadIndex(Node<kK,V> node, Index<K,V> down, Index<K,V> 
right, int level) { 


super(node, down, right); 


this.level = level; 


这 样 核心 的 内 部 元 素 就 介绍 完成 了 。 对 于 跳 表 的 所 有 操作 ， 束 是 
组 织 好 这 些 Index 之 间 的 连接 关系 。 


3.4 参考 资料 


。 这 篇 博客 讲解 了 ScheduledThreadPoolExecutor 的 使 用 注意 事项 
o http://segmentfault.com/a/1190000000371905 


这 里 讲解 了 儿 个 有 关 线 程 池 的 使 用 技巧 


o http://it.deepinmind.com/java/2014/11/26/executorservice-10- 
tips-and-tricks.html 


。 有 关 Fork/Join 的 简单 实现 原理 
o http://www.infog.com/cn/articles/fork-join-introduction 


。 有 关 ConcurrentLinkedQueue 的 实现 具体 分 析 (其 使 用 的 JDK 版 
本 与 本 书 不 同 ) 


o http://my.oschina.net/xianggao/blog/389332 


o http://www.ibm.com/developerworks/cn/java/j-lo-concurrent/ 
。 有关 ConcurrentSkipListMap 的 运作 原理 〈 示 例 图 示 很 好 ) 


o http://www.liuhaihua.cn/archives/40657.html 


第 4 章 ” 锁 的 优化 及 注意 事项 


“ 锁 ? 是 最 音 用 的 同步 方法 之 一 。 在 高 并 发 的 环境 下 ， 激 烈 的 锁 葛 


争 会 导致 程序 的 性 能 下 降 。 所 以 我 们 自然 有 必要 讨论 一 些 有 关 * 锁 ”的 
性 能 问题 以 及 相关 一 些 注意 事项 。 比 如 ， 吉 免 死 锁 、 减 小 锁 粒度 、 锁 
分 离 等 。 


在 多 核 时 代 ， 使 用 多 线程 可 以 明显 地 提高 系统 的 性 能 。 但 事实 
上 ， 使 用 多 线程 的 方式 会 额外 增加 系统 的 开销 。 


对 于 单 任务 或 者 单线 程 的 应 用 而 言 ， 其 主要 资源 消耗 都 伦 在 任务 
本 吴 。 它 既 不 需要 维护 并 行 数据 结构 间 的 一 致 性 状态 ， 也 不 需要 为 线 
程 的 切换 和 调度 花费 时 间 。 但 对 于 多 线程 应 用 来 说 ， 系 统 除了 处 理 功 
能 需求 外 ， 还 需要 额外 维护 多 线程 环境 的 特有 信息 ， 如 线程 本 号 的 元 
数据 、 线 程 的 调度 、 线 程 上 下 文 的 切换 等 。 


事实 上 ， 在 单 核 CPU 上 ， 采 用 并 行 算法 的 效率 一 般 要 低 于 原始 的 
串 行 算法 的 ， 其 根本 原因 也 在 于 此 。 因 此 ， 并 行 计算 之 所 以 能 提高 系 
统 的 性 能 ， 并 不 是 因为 它 “ 少 干 活 ”了 ， 而 是 因为 并 行 计算 可 以 更 合理 
地 进行 任务 调度 ， 充 分 利用 各 个 CPU 资 源 。 因 此 ， 合 理 的 并 发 ， 才 能 
将 多 核 CPU 的 性 能 发 挥 到 极致 。 


4.1 有 助 于 提高 “ 锁 ” 性 能 的 几 点 建 
议 


“ 锁 ” 的 竞争 必然 会 导致 程 序 的 整体 性 能 下 降 。 为 了 将 这 种 副作用 
降 到 最 低 ， 我 这 里 提出 一 些 天 于 使 用 锁 的 建议 , 希望 可 以 帮助 大 家 写 
出 性 能 更 为 优越 的 程序 。 


4.1.1 ” 减 小 锁 持 有 了 时间 


对 于 使 用 锁 进 行 并 发 控制 的 应 用 程序 而 言 ， 在 锁 竞 争 过程 中 ， 单 
个 线程 对 锁 的 持 有 时 间 与 系统 性 能 有 着 直接 的 关系 。 如 采 线 程 持 有 锁 
的 时 间 很 长 ， 那 么 相对 地 ， 锁 的 范 争 程度 也 就 越 激 烈 。 可 以 想象 一 
下 ， 如 有 果 要 求 100 个 人 各 目 填写 目 己 的 吴 份 信息 ， 但 是 只 给 他 们 一 文 
E o 那么 如 果 每 个 人 拿 着 笔 的 时 间 都 很 长 ， 总 体 所 人 论 的 时 间 束 会 很 
长 。 如 果真 的 只 能 有 一 支 笔 共享 给 100 个 人 用 ， 那 么 最 好 就 让 每 个 人 花 
尽量 少 的 时 间 持 笔 ， 务 必 做 到 想 好 了 再 拿 笔 写 ， 干 万 不 可 拿 厦 笔 才 去 
思考 这 表格 应 该 上 怎么 填 。 程 序 开发 也 是 类 似 的 ， 应 该 尽 可 能 地 减少 对 
某 个 锁 的 占有 了 时间， 以 减少 线程 间 互 不 的 可 能 。 以 下 面 的 代码 段 为 
例 : 


public synchronized void syncMethod(){ 
othercode1(); 
mutextMethod(); 


othercode2(); 


syncMethod0 方 法 中 ， 假 设 只 有 mutextMethod(0) 方 法 是 有 同步 需要 
的 ， 而 othercode10 和 othercode2() 并 不 需要 做 同步 控制 。 如 果 
othercode1() 和 othercode2() 分 别 是 重量 级 的 方法 ， 则 会 花费 较 长 的 CPU 
时 间 。 此 时 ， 如 果 在 并 发 量 较 大 ， 使 用 这 种 对 整个 方法 做 同步 的 方 


案 ， 会 导致 等 行 线程 大 量 增 加 。 因 为 一 个 线程 ， 在 进入 该 方法 时 获得 
内 部 锁 Ta, Tae ° 


NBO TCH PRT RE, ATED RET IA, ORE BEA 
显 城 少 线程 持 有 锁 的 时 间 ， 近 高 系统 的 春 叶 量 。 


public void syncMethod2(){ 
othercode1(); 
synchronized(this) { 
mutextMethod(); 


} 
othercode2(); 


在 改进 的 代码 中 ， 只 针对 mutextMethod(0) 方 法 做 了 同步 ， 锁 占用 
的 时 间 相 对 较 短 ， 因 此 能 有 更 高 的 并 行 度 。 这 种 技术 手段 在 JDK 的 源 
码 包 中 也 可 以 很 容易 地 找到 ， 比 如 处 理 正则 表达 式 的 Pattern 类 : 


public Matcher matcher(CharSequence input) { 
if (!compiled) { 
synchronized(this) { 
if (!compiled) 


compile(); 


t 
Matcher m = new Matcher(this, input); 


return m; 


matcher(0) 方 法 有 条 件 地 进行 锁 申 请 ， 只 有 在 表达 式 未 编译 时 ， 进 
行 局 部 的 加 锁 。 这 种 处 理 方式 大 大 提高 了 matcher(0 方 法 的 执行 效率 和 
可 靠 性 。 


注意 : 减少 锁 的 择 有 时 间 有 助 于 降低 锁 冲 突 的 可 能 性 ， 进 而 提升 
系统 的 并 发 能 


4.1.2 Ya BORE 


减 小 锁 粒 度 也 是 一 种 削弱 多 线程 锁 竞 争 的 有 殖 手 段 。 这 种 技术 典 
型 的 使 用 场景 就 是 ConcurrentHashMap 类 的 实现 。 大 家 应 该 还 记得 这 个 
RIE! 在 “3.3JDK 的 并 发 容器 ”一 和 中 ， 我 向 大 家 介绍 了 这 个 高 性 能 的 
HashMap。 但 是 当时 我 们 并 没有 说 明 它 的 实现 原理 。 这 里 ， 让 我 们 更 
加 细致 地 看 一 下 这 个 类 。 


对 于 HashMap 来 说 ， 最 重要 的 两 个 方法 束 是 getO 〇 和 put()。 一 种 最 
目 然 的 想法 承 是 对 整个 HashMap 加 锁 ， 必 然 可 以 得 到 一 个 线程 安全 的 
对 象 。 但 是 这 样 做 ， 我 们 束 认 为 加 锁 粒 度 太 大 。 对 于 
ConcurrentHashMap， 它 内 部 进一步 细 分 了 若干 个 小 的 HashMap， 称 之 
为 段 (SEGMENT) 。 默 认 情 况 下 ， 一 个 ConcurrentHashMap 被 进一步 
细 分 为 16 个 段 。 


如 果 需 要 在 ConcurrentHashMap 中 增加 一 个 新 的 表 项 ， 并 不 是 将 整 
个 HashMap 加 锁 ， 而 是 首先 根据 hashcode 得 到 该 表 项 应 该 被 存放 到 哪 
个 段 中 ， 然 后 对 该 段 加 锁 ， 并 完成 putO 操 作 。 在 多 线程 环境 中 ， 如 采 
多 个 线程 同时 进行 put0 操 作 ， 只 要 被 加 入 的 表 项 不 存放 在 同一 个 段 
中 ， 则 线程 间 便 可 以 做 到 真正 的 并 行 。 


由 于 默认 有 16 个 段 ， 因 此 ， 如 有 果 人 够 幸运 的 话 ，ConcurrentHashMap 
可 以 同时 接受 16 个 线程 同时 插入 (如 有 果 都 插入 不 同 的 段 中 ) ， 从 而 大 
大 提供 其 吞吐 量 。 下 面 代码 显示 了 put0 探 作 的 过 程 。 在 第 5~6 行 ， 根 
据 key， 获 得 对 应 的 段 的 序号 。 接 着 在 第 9 行 ， 得 到 段 ， 然 后 将 数据 插 
入 给 定 的 段 中 。 


01 public V put(K key, V value) { 


02 Segment <K,V> s; 

03 if (value == null) 

04 throw new NullPointerException(); 

05 int hash = hash(key); 

06 int j = (hash >>> segmentShift) & segmentMask; 

07 if ((S = (Segment <K, V> )UNSAFE.getObject 


// nonvolatile; recheck 
08 (segments, (j << SSHIFT) + SBASE)) == null) 


// in ensureSegment 


09 s = ensureSegment(j); 
10 return s.put(key, hash, value, false); 
11 } 


但 是 ， 减 少 锁 粒 度 会 引入 一 个 新 的 问题 ， 即 : 当 系 统 需要 取得 全 
局 锁 时 ， 其 消耗 的 资源 会 比较 多 。 仍 然 以 ConcurrentHashMap 类 为 例 ， 
虽然 其 put0 方 法 很 好 地 分 离 了 锁 ， 但 是 当 试 图 访问 ConcurrentHashMap 
全 局 信息 时 ， 束 会 需要 同时 取得 所 有 上段 的 锁 方 能 顺利 实施 。 比 如 
ConcurrentHashMap 的 size() 方 法 ， 它 将 返回 ConcurrentHashMap 的 有 效 
表 项 的 数量 ， 即 ConcurrentHashMap 的 全 部 有 效 表 项 之 和 。 要 获取 这 个 
信息 需要 取得 所 有 子 段 的 锁 ， 因 此 ， 其 size0) 方 法 的 部 分 代码 如 下 : 


sum = 0; 


for (int i = 0; i < segments.length; ++i) // 对 所 
有 的 段 加 锁 
segments[i].lock(); 
for (int i = 0; i < segments.length; ++i) // 统 计 
sum += segments[i].count; 
for (int i = 0; i < segments.length; ++i) / / FETS 
所 有 的 锁 


segments[i].unlock(); 


可 以 看 到 在 计算 总 数 时 ， 先 要 获得 所 有 上 段 的 锁 ， 然 后 再 求 和 。 但 
是 ，ConcurrentHashMap 的 size0) 方 法 并 不 总 是 这 样 执行 ， 事实 上 ， 
size() 方 法 会 完 使 用 无 锁 的 方式 求 和 ， 如 果 失 败 才 会 尝试 这 种 加 锁 的 方 
法 。 但 不 管 这 么 说 ， 在 高 并 发 场合 ConcurrentHashMap 的 size() 的 性 能 
依然 要 差 于 同步 的 HashMap 。 


此 ， 只 有 在 类 似 于 size() 获 取 全 局 信息 的 方法 调用 并 不 频繁 时 ， 
这 种 城 小 锁 粒 度 的 方法 才能 真正 意义 上 提高 系统 吞吐 量 。 


TER: 所 谓 减 少 锁 粒 度 ， 就 是 指 缩小 锁定 对 象 的 范围 ， 从 而 减少 
锁 冲 突 的 可 能 性 ， 进 而 提高 系统 的 并 发 能 力 。 


4.1.3” 读 写 分 离 锁 来 蔡 换 独占 锁 


在 之 前 我 们 已 经 提 过 ， 使 用 读 写 锁 ReadWriteLock 可 以 提高 系统 的 
性 能 。 使 用 读 写 分 离 锁 来 瑟 代 独占 锁 是 减 小 锁 粒 度 的 一 种 特殊 情况 。 


如 果 说 上 节 中 提 到 的 减少 锁 粒 大 是 通过 分 割 数据 结构 实现 的 ， 那 么 ， 
读 写 锁 则 是 对 系统 功能 点 的 分 割 。 


在 读 多 写 少 的 场合 ， 读 写 锁 对 系统 性 能 是 很 有 好 处 的 。 因 为 如 果 
系统 在 读 写 数据 时 均 只 使 用 独占 锁 ， 那 么 读 操 作 和 写 操作 间 、 读 操作 
和 读 操 作 间 、 写 操作 和 写 操作 间 均 不 能 做 到 真正 的 并 发 ， 并 且 需 要 相 
互 等 待 。 而 读 操作 本 吴 不 会 影响 数据 的 完整 性 和 一 致 性 。 因 此 ， 理 论 
上 讲 ， 在 大 部 分 情况 下 ， 应 该 可 以 允许 多 线程 同时 读 ， 读 写 锁 正 征 实 
现 了 这 种 功能 。 由 于 我 们 在 第 3 章 中 已 经 介绍 了 读 写 锁 ， 因 此 这 里 融 不 
再 重复 了 。 


注意 : 在 读 多 写 少 的 场合 ， 使 用 读 写 锁 可 以 有 效 提 升 系统 的 并 发 


41.4 BOB 


如 果 将 读 写 锁 的 思想 做 进一步 的 延伸 ， 残 是 锁 分 离 。 读 写 锁 根 据 
读 写 操作 功能 上 的 不 同 ， 进 行 了 有 效 的 锁 分 离 。 依 据 应 用 程序 的 功能 
特点 ， 使 用 类 似 的 分 离 思想 ， 也 可 以 对 独占 锁 进 行 分 离 。 一 个 典型 的 
案例 就 是 java.utilconcurrent.LinkedBlockingQueue 的 实现 (如 果 大 家 印 
象 深刻 ， 我 们 在 之 前 已 经 讨论 了 它 的 近亲 ArrayBlockingQueue 的 内 部 
实现 ) 


7£LinkedBlockingQueuel ZMH, takeQ HALA put() BLA a SH 
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当前 队列 进行 了 修改 操作 ， 但 由 于 LinkedBlockingQueue 是 基于 链表 


的 ， 因 此 ， 两 个 操作 分 别 作用 于 队列 的 前 端 和 尾 端 ， 从 理论 上 说 ， 两 
者 并 不 冲突 。 


如 果 使 用 独占 锁 ， 则 要 求 在 两 个 操作 进行 时 获取 当前 队列 的 独占 
锁 ， 那 么 take() 和 put() 操 作 束 不 可 能 真正 的 并 发 ， 在 运行 时 ， 它 们 会 彼 
此 等 每 对 方 释放 锁 资 源 。 在 这 种 情况 下 ， 锁 竞争 会 相对 比较 激烈 ， 从 
而 影响 程序 在 高 并 发 时 的 性 能 。 


因此 ， 在 JDK 的 实现 中 ， 并 没有 采用 这 样 的 方式 ， 取 而 代 之 的 是 
两 把 不 同 的 锁 ， 分 离 了 take0 和 putO 操 作 。 


/** Lock held by take, poll, etc */ 

private final ReentrantLock takeLock = new ReentrantLock(); 
//take() Rat Bis takeLock 

/** Wait queue for waiting takes */ 

private final Condition notEmpty = takeLock.newCondition(); 

/** Lock held by put, offer, etc */ 

private final ReentrantLock putLock = new ReentrantLock(); 
//put () NaN 244A put Lock 


/** Wait queue for waiting puts */ 


private final Condition notFull = putLock.newCondition(); 


以 上 代码 片段 ， 定 义 了 takeLock 和 putLock， 它 们 分 别 在 take0O 操 作 
和 put() 控 作 中 使 用 。 因 此 ，take() 函 数 和 put() 函 数 就 此 相互 独立 ， 它 们 
之 间 不 存在 锁 竞 争 关系 ， 只 需要 在 take0 和 take0 间 、putO0 和 putO 间 分 
别 对 takeLock 和 putLock 进 行 莞 争 。 从 而 ， 削 弱 了 锁 苋 争 的 可 能 性 。 


函数 take0 的 实现 如 下 ， 笔 者 在 代码 中 给 出 了 详细 的 注释 ， 故 不 在 
正文 中 做 进一步 说 明 。 


public E take() throws InterruptedException { 
ERDO; 
int c = -1; 
final AtomicInteger count = this.count; 


final ReentrantLock takeLock = this.takeLock; 


takeLock.lockInterruptibly(); // 不 能 
两 个 线程 同时 取 数 据 
try { 
try { 
while (count.get() == 0) // 如 果 当 
前 没有 可 用 数据 ， 一 直 等 待 
notEmpty.await(); // 等 待 ， 
put ( ) 操 作 的 通知 
} catch (InterruptedException ie) { 
notEmpty.signal(); // 通 知 其 
他 未 中 断 的 线程 
throw ie; 
} 
x = extract(); // 取 得 第 
= 
c = count.getAndDecrement(); // 数 量 减 


1， 原 子 操 作 ， 因 为 会 和 put() 
// 函 数 同 时 访问 count。 注 意 : 变量 c 是 


//count 减 1 前 的 值 


(GC > L) 
notEmpty.signal(); // 通 知 其 
他 take() 操 作 
} finally { 
takeLock.unlock(); // 释 放 锁 
} 
if (c == capacity) 
signalNotFull(); // 通 知 
put ( ) 操 作 ， 已 有 空余 空间 
return x; 
} 
函数 put0) 的 实现 如 下 ， 
public void put(E e) throws InterruptedException { 
if (e == null) throw new NullPointerException(); 
int c = -1; 
final ReentrantLock putLock = this.putLock; 
final AtomicInteger count = this.count; 
putLock.lockInterruptibly(); // 不 能 有 两 
个 线程 同时 进行 put ( ) 
try { 
try { 
while (count.get() == capacity) // 如 果 队 列 
已 经 满 了 


notFull.await(); // 等 待 


} catch (InterruptedException ie) { 


notFull.signal(); 
WT AGRE 
throw ie; 
} 
insert(e); 
c = count.getAndIncrement(); 
数 ， 变 量 c 是 count 加 1 前 的 值 


if (c + 1 < capacity) 


notFull.signal(); 
空间 ， 通 知 其 他 线程 
} finally { 


putLock.unlock(); 
I 
in (C == 0) 
signalNotEmpty(); 
后 ， 通 知 take( ) 操 作 取 数 据 


// 通 知 未 中 


// 有 足够 的 


// 释 放 锁 


// 插 入 成 功 


通过 takeLock 和 putLock 两 把 锁 ，LinkedBlockingQueue 实 现 了 取 数 
据 和 写 数据 的 分 离 ， 使 两 者 在 真正 意义 上 成 为 可 并 发 的 操作 © 


4.1.5” 锁 粗 化 


通 第 情况 下 ， 为 了 保证 多 线程 间 的 有 效 并 发 ， 会 要 求 每 个 线程 持 
有 锁 的 时 间 尽 量 短 ， 即 在 使 用 完 公共 资源 后 ， 应 该 立即 释放 锁 。 只 


这 样 ， 等 竺 在 这 个 锁 上 的 其 他 线程 才能 尽早 地 获得 资源 执行 任务 。 但 
征 ， 凡 事 都 有 一 个 度 ， 如 果 对 同一 个 锁 不 停 地 进行 请 求 、 同 步 和 释 
放 ， 其 本 和 映 也 会 消耗 系统 宝 叶 的 资源 ， 反 而 不 利于 性 能 的 优化 。 


为 此 ， 虚 拟 机 在 遇 到 一 连 串 连续 地 对 同一 锁 不 断 进 行 请 求 和 释放 
的 操作 时 ， 便 会 把 所 有 的 锁 操 作 整 合成 对 锁 的 一 次 请 求 ， 从 而 减少 对 
锁 的 请 求 同 步 次 数 ， 这 个 操作 叫做 锁 的 粗 化 。 比 如 代码 段 : 


public void demoMethod(){ 
synchronized(lock) { 
//do sth. 
t 
// 做 其 他 不 需要 的 同步 的 工作 ， 但 能 很 快 执行 完毕 


synchronized(lock) { 


//do sth. 


会 被 整合 成 如 下 形式 : 


public void demoMethod() { 
// 整 合成 一 次 锁 请 求 


synchronized(lock) { 


//do sth. 
// 做 其 他 不 需要 的 同步 的 工作 ， 但 能 很 快 执行 完毕 


在 开发 过 程 中 ， 大 家 也 应 该 有 意识 地 在 合理 的 场合 进行 锁 的 粗 
化 ,尤其 当 在 循环 内 请 求 锁 时 。 以 下 是 一 个 循环 内 请 求 锁 的 例 于 ， 在 
这 种 情况 下 ， 意 味 着 每 次 循环 都 有 申请 锁 和 释放 锁 的 操作 。 但 在 这 种 
情况 下 ， 显 然 是 没有 必要 的 。 


for(int i=0;i<CIRCLE;i++){ 


synchronized(lock) { 

t 
t 

所 以 ， 一 种 更 加 合理 的 做 法 应 该 是 在 外 层 只 请 求 一 次 锁 : 
synchronized(lock) { 


for(int 1=0;1<CIRCLE;i++){ 


注意 : 性 能 优化 就 是 根据 运行 时 的 真实 情况 对 各 个 资源 点 进行 权 
衡 折 中 的 过 程 。 锁 粗 化 的 思想 和 减少 锁 持 有 时 间 是 相反 的 ， 但 在 
不 同 的 场合 ， 它 们 的 效果 并 不 相同 。 所 以 大 家 需要 根据 实际 情 
况 ， 进 行 权 衡 。 


Java 虚 拟 机 对 锁 优 化 所 做 的 努 


作为 一 款 共 用 平台 ，JDK 本 喘 也 为 并 发 程序 的 性 能 绞 尽 脑汁 。 在 
JDK 内 部 也 想 尽 一 切 办 法 提供 并 发 时 的 系统 吞吐 量 。 这 里 ， 我 将 向 大 
家 简单 介绍 儿 种 JDK 内 部 的 “ 锁 ? 优 化 策略 。 


4.2.1 Sii 


锁 偏 回 是 一 种 针对 加 锁 操作 的 优化 手段 。 它 的 核心 思想 是 : 如 和 采 
一 个 线程 获得 了 锁 ， 那 么 锁 束 进入 偏 问 模式 。 当 这 个 线程 再 次 请 求 锁 
时 ， 无 须 再 做 任何 同步 操作 。 这 样 就 节省 了 大 量 有 关 锁 申请 的 操作 ， 
从 而 提高 了 程序 性 能 。 因 此 ， 对 于 几乎 没有 锁 竞 争 的 场合 ， 偏 问 锁 有 
比较 好 的 优化 效果 ， 因 为 连续 多 次 极 有 可 能 是 同一 个 线程 请 求 相同 的 
锁 。 而 对 于 锁 竞 和 争 比 较 激 烈 的 场合 ， 其 效果 不 佳 。 因 为 在 竞争 激烈 的 
场合 ， 最 有 可 能 的 情况 是 每 次 都 是 不 同 的 线程 来 请 求 相同 的 锁 。 这 样 
偏 回 模式 会 失效 ， 因 此 还 不 如 不 启用 偏 同 锁 。 使 用 Java 虚 拟 机 参数 - 
XX:+UseBiasedLocking FJ LAFF IA fa mI e 。 


4.2.2” 轻 量 级 锁 


如 果 偏 向 锁 失败 ， 虚 拟 机 并 不 会 立即 挂 起 线程 。 它 还 会 使 用 一 种 
称 为 轻 量 级 锁 的 优化 手段 。 轻 量 级 锁 的 操作 也 很 轻便 ， 它 只 十 简单 地 


将 对 象 头 部 作为 指针 ， 指 癌 持 有 锁 的 线程 堆栈 的 内 部 ， 来 判断 一 个 线 
程 是 否 持 有 对 象山。 如 果 线 程 获得 轻 量 级 锁 成 功 ， 则 可 以 顺利 进入 临 
界 区 。 如 果 轻 量 级 锁 加 锁 失 败 ， 则 表示 其 他 线程 抢先 争夺 到 了 锁 ， 那 
么 当前 线程 的 锁 请 求 束 会 膨胀 为 重量 级 锁 。 


4.2.3 ” 自 旋 锁 


锁 膨 胀 后 ， 虚 拟 机 为 了 避免 线程 真实 地 在 操作 系统 层面 挂 起 ， 虚 
拟 机 还 会 在 做 最 后 的 努力 自 旋 锁 。 由 于 当前 线程 暂时 无 法 获得 
锁 ， 但 是 什么 时 候 可 以 获得 锁 是 一 个 未 知 数 。 也 许 在 几 个 CPU 时 钟 周 
期 后 ， 束 可 以 得 到 锁 。 如 有 果 这 样 ， 简 单 粗 又 地 挂 起 线程 可 能 是 一 种 得 
不 偿 失 的 操作 。 因 此 ， 系 统 会 进行 一 次 贱 注 ， 它 会 假设 在 不 久 的 将 
来 ， 线 程 可 以 得 到 这 把 锁 。 因 此 ， 虚 拟 机 会 让 当前 线程 做 儿 个 空 循环 

(这 也 是 自 旋 的 含义 ) ， 在 经 过 若干 次 循环 后 ， 如 果 可 以 得 到 锁 ， 那 
么 驶 顺利 进入 临界 区 。 如 采 还 不 能 获得 锁 ， 才 会 真实 地 将 线程 在 操作 
系统 层面 挂 起 。 


4.2.4 BURR 


锁 消 除 是 一 种 更 彻底 的 锁 优化 。Java 虚 拟 机 在 JIT 编 译 时 ， 通 过 对 
Att ER SCAT, ARNE] Be ES BTR eA to RS 
BR, AY LAT PS TCS ATLA TA] o 


说 到 这 里 ， 细 心 的 读者 可 能 会 产生 疑问 ， 如 果 不 可 能 存在 竞争 ， 
为 什么 程序 员 还 要 加 上 锁 呢 ?这 是 因为 在 Java 软 件 开发 过 程 中 ， 我 们 
必然 会 使 用 一 些 JDK 的 内 置 API， 比 如 StringBuffer、Vector 等 。 你 在 使 


用 这 些 类 的 时 候 ， 也 许 根本 不 会 考虑 这 些 对 象 到 底 内 部 是 如 何 实现 
的 。 比 如 ， 你 很 有 可 能 在 一 个 不 可 能 存在 并 发 竞争 的 场合 使 用 
Vector。 而 众所周知 ，Vector 内 部 使 用 了 synchronized 请 求 锁 。 比 如 下 
面 的 代码 : 


public String[] createStrings(){ 
Vector<String> v=new Vector<String>(); 
for(int i1=0;i1<100;i++){ 
v.add(Integer.toString(1)); 
ii 
return v.toArray(new String[]{}); 


注意 上 述 代码 中 的 Vector， 由 于 变量 v 只 在 createStrings() 芳 数 中 使 
用 ， 因 此 ， 它 只 是 一 个 单纯 的 局 部 变量 。 局 部 变量 是 在 线程 栈 上 分 配 
的 ， 属 于 线程 私有 的 数据 ， 因 此 不 可 能 被 其 他 线程 访问 。 所 以 ， 在 这 
种 情况 下 ，YVector 内 部 所 有 加 锁 同 步 都 是 没有 必要 的 。 如 采 虚 拟 机 检 
测 到 这 种 情况 ， 束 会 将 这 些 无 用 的 锁 操作 去 除 。 


锁 消 除 涉 及 的 一 项 关键 技术 为 逃逸 分 机 。 所 谓 逃 逸 分 析 歌 是 观察 
某 一 个 变量 是 否 会 逃 出 某 一 个 作用 域 。 在 本 例 中 ， 变 量 v 显 然 没 有 逃 出 
createStrings() 落 数 之 外 。 以 次 为 基础 ， 虚 拟 机 才 可 以 大 胆 地 将 v 内 部 的 
加 锁 操 作 去 除 。 如 果 createStrings0 返 回 的 不 是 String 数 组 ， 而 是 v 本 
了 村， 那么 承认 为 变量 v 逃 锡 出 了 当前 函数 ， 也 就 是 说 v 有 可 能 被 其 他 线 
程 访问 。 如 有 果 是 这 样 ， 虚 拟 机 吏 不 能 消除 v 中 的 锁 操 作 。 


逃逸 分 析 必 须 在 -server 模 式 下 进行 ， 可 以 使 用 - 
XX:+DoEscapeAnalysis A a7) FF bi 57 Hr o (EH -XX:+EliminateLocks 


参数 可 以 打开 锁 消 除 。 


4.3 ” 人手 一 文笔 : ThreadLocal 


除了 控制 资源 的 访问 外 ， 我 们 还 可 以 通过 增加 资源 来 保证 所 有 对 
象 的 线程 安全 。 比 如 ， 让 100 个 人 填写 个 人 信息 表 ， 如 果 只 有 一 文笔 ， 
那么 大 家 就 得 挨个 填写 ， 对 于 管理 人 员 来 说 ， 必 须 保 证 大 家 不 会 去 哄 
抢 这 仅 存 的 一 文笔 ， 否 则 ， 谁 也 填 不 完 。 从 另外 一 个 角度 出 发 ， 我 们 
可 以 干脆 吏 准 备 100 文 笔 ， 人 和 手 一 文 ， 那 么 所 有 人 都 可 以 各 目 为 昔 ， 很 
快 践 能 完成 表格 的 填写 工作 。 


如 果 说 锁 是 使 用 第 一 种 思路 ， 那 么 ThreadLocal 豆 是 使 用 第 二 种 思 
路 了 。 


4.3.1 ThreadLocal 的 简单 使 用 


从 ThreadLocal 的 名 字 上 可 以 看 到 ， 这 古 一 个 线程 的 局 部 变量 。 也 
忠 是 说 ， 只 有 当前 线程 可 以 访问 。 既 然 钙 上 只 有 当前 线程 可 以 访问 的 数 
据 ， 自 然 是 线程 安全 的 。 


下 面 来 看 一 个 倍 单 的 示例 : 


01 private static final SimpleDateFormat sdf = new 
SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); 

02 public static class ParseDate implements Runnable{ 

03 int 1=0; 


04 public ParseDate(int i){this.i=1i;} 


05 public void run() { 


06 try { 

07 Date t=sdf.parse("2015-03-29 19:29:"+i%60); 
08 System.out.println(i+":"+t); 

09 } catch (ParseException e) { 

10 e.printStackTrace(); 

11 } 

12 } 

13 } 


14 public static void main(String[] args) { 


15 ExecutorService es=Executors.newFixedThreadPool(10); 
16 for(int 1=0;1<1000;1i++){ 

17 es.execute(new ParseDate(i)); 

18 } 

19 } 


上 述 代 码 在 多 线程 中 使 用 SimpleDateFormat 来 解析 字符 串 类 型 的 
日 期 。 如 果 你 执行 上 述 代 码 ， 一 般 来 说 ， 你 很 可 能 得 到 一 些 异 常 (篇 
幅 有 限 不 再 给 出 堆栈 ， 只 给 出 异常 名 称 ) 


Exception in thread "pool-1-thread-26" 
java.lang.NumberFormatException: For input string: "" 
Exception in thread "pool-1-thread-17" 


java.lang.NumberFormatException: multiple points 


出 现 这 些 问 题 的 原因 ， 是 SimipleDateFormat.parse(0) 方 法 并 不 是 线 
程 安全 的 。 因 此 ， 在 线程 池 中 共享 这 个 对 象 必 然 导 致 错误 © 


一 种 可 行 的 方案 是 在 sdf.parse() 前 后 加 锁 ， 这 也 是 我 们 一 般 的 处 理 
思路 。 这 里 我 们 不 这 么 做 ， 我 们 使 用 ThreadLocal 为 每 一 个 线程 都 产生 
一 个 SimpleDateformat 对 象 实 例 : 


01 static ThreadLocal<SimpleDateFormat> tl=new ThreadLocal< 
SimpleDateFormat > ()j; 


02 public static class ParseDate implements Runnable{ 


03 int i=0; 

04 public ParseDate(int 1i){this.i=i;} 

05 public void run() { 

06 try { 

07 if(tl.get()==null){ 

08 tl.set(new SimpleDateFormat("yyyy-MM-dd 


HH:mm:ss")); 


09 } 

10 Date t=tl.get().parse("2015-03-29 19:29:"+1%60); 
11 System.out.printin(it+":"+t); 

12 } catch (ParseException e) { 

13 e.printStackTrace(); 

14 } 

15 } 

16 } 


上 述 代 码 第 7~9 行 ， 如 果 当 前 线程 不 持 有 SimpleDateformat 对 象 实 
例 。 那 么 惑 狐 建 一 个 并 把 它 设置 到 当前 线程 中 ， 如 果 已 经 持 有 ， 则 和 直 
接 使 用 。 


从 这 里 也 可 以 看 到 ， 为 每 一 个 线程 人 手 分 配 一 个 对 象 的 工作 并 不 
是 由 ThreadLocal 来 完成 的 ， 而 是 需要 在 应 用 层面 保证 的 。 如 果 在 应 用 
上 为 每 一 个 线程 分 配 了 相同 的 对 象 实例 ， 那 么 ThreadLocal 也 不 能 保证 
线程 安全 。 这 点 也 需要 大 家 注意 。 


注意 : 为 每 一 个 线程 分 配 不 同 的 对 象 ， 需 要 在 应 用 层面 保证 。 
ThreadLocal 只 是 起 到 了 人 简单 的 容 姨 作用 。 


4.3.2 ThreadLocal 的 实现 原理 


那 ThreadLocal 又 是 如 何 保 证 这 些 对 象 只 被 当前 线程 所 访问 昵 ? 下 
面 让 我 们 一 起 深入 ThreadLocal 的 内 部 实现 。 


我 们 需要 关注 的 ， 目 然 是 ThreadLocal 的 set() 方 法 和 getO 方 法 。 从 
set() 方 法 先 说 起 : 


public void set(T value) { 
Thread t = Thread.currentThread(); 
ThreadLocalMap map = getMap(t); 
if (map != null) 
map.set(this, value); 
else 


createMap(t, value); 


在 set 时 ， 首 先 获得 当前 线程 对 象 ， 然 后 通过 getMap() 拿 到 线程 的 
ThreadLocalMap ， 并 将 值 设 入 ThreadLocalMap 中 。 而 ThreadLocalMap 


可 以 理解 为 一 个 Map (虽然 不 是 ， 但 是 你 可 以 把 它 简 单 地 理解 成 
HashMap) ， 但 是 它 是 定义 在 Thread 内 部 的 成 员 。 注 意 下 面 的 定义 是 
从 Thread 类 中 摘出 来 的 : 


ThreadLocal.ThreadLocalMap threadLocals = null; 


而 设置 到 ThreadLocal 中 的 数据 ， 也 正 是 写 入 了 threadLocals 这 个 
Map。 其 中 ，key 为 ThreadLocal 当 前 对 象 ，value 就 是 我 们 需要 的 值 。 
而 threadLocals 本 号 职 保存 了 当前 目 己 所 在 线程 的 所 有 “局 部 变量 ”， 也 


了 驶 是 一 个 ThreadLocal 变 量 的 集合 


在 进行 getO 操 作 时 ， 目 然 殉 是 将 这 个 Map 中 的 数据 拿 出 来 : 


public T get() { 
Thread t = Thread.currentThread(); 
ThreadLocalMap map = getMap(t); 
if (map != null) { 
ThreadLocalMap.Entry e = map.getEntry(this); 
if (e != null) 
return (T)e.value; 


} 


return setInitialValue(); 


首先 ，get(0) 方 法 也 是 先 取 得 当前 线程 的 ThreadLocalMap 对 象 。 然 
后 ， 通 过 将 目 己 作为 key 取 得 内 部 的 实际 数据 。 


在 了 解 了 ThreadLocal 的 内 部 实现 后 ， 我 们 目 然 会 引出 一 个 问题 。 
那 就 是 这 些 变 量 是 维护 在 Thread 类 内 部 的 (ThreadLocalMap 定 义 所 在 


类 ) ， 这 也 意味 着 只 要 线程 不 退出 ， 对 象 的 引用 将 一 直 存在 。 


当 线 程 退出 时 ，Thread 类 会 进行 一 些 清 理工 作 ， 其 中 就 包括 清理 
ThreadLocalMap， 注 意 下 述 代 码 - í 1 粗 部 分 

WE 

* 在 线程 退出 前 ， 由 系统 回调 ， 进 行 资源 清理 

Wk 


private void exit() { 
if (group != null) { 
group.threadTerminated(this); 
group = null; 
hi 
target = null; 
/* 加 速 资 源 清理 */ 


threadLocals = null; 


inheritableThreadLocals = null; 
inheritedAccessControlContext = null; 
blocker = null; 
uncaughtExceptionHandler = null; 


i 


因此 ， 如 有 果 我 们 使 用 线程 池 ， 那 就 意味 着 当前 线程 未 必 会 退出 
《比如 固定 大 小 的 线程 池 ， 线 程 总 是 存在 ) 。 如 果 这 样 ， 将 一 些 大 大 
的 对 象 设置 到 ThreadLocal 中 〈 它 实际 保存 在 线程 持 有 的 threadLocals 
Map 内 ) ， 可 能 会 使 系统 出 现 内 存 泄露 的 可 能 (这 里 我 的 意思 是 : 你 
设置 了 对 象 到 ThreadLocal 中 ， 但 是 不 清理 它 ， 在 你 使 用 几 次 后 ， 这 个 
对 象 也 不 再 有 用 了 ， 但 是 它 却 无 法 被 回收 ) 。 


此 时 ， 如 有 果 你 希望 及 时 回收 对 象 ， 最 好 使 用 ThreadLocalremove() 
方法 将 这 个 变量 移 除 。 就 像 我 们 习惯 性 地 关闭 数据 库 连 接 一 样 。 如 果 
你 确实 不 需要 这 个 对 象 了 了， 那么 束 应 该 告诉 虚拟 机 ， 请 把 它 回 收 挥 ， 
防止 内 存 泄露 。 


另外 一 种 有 趣 的 情况 是 JDK 也 可 能 允许 你 像 释放 普通 变量 一 样 释 
放 ThreadLocal。 比 如 ， 我 们 有 时 候 为 了 加 速 垃圾 回收 ， 会 特意 写 出 类 
似 obj=null 之 类 的 代码 。 如 果 这 么 做 ，obj 所 指向 的 对 象 就 会 更 容易 地 
被 垃圾 回收 器 发 现 ， 从 而 加 速 回收 。 


同 理 ， 如 果 对 于 ThreadLocal 的 变量 ， 我 们 也 手动 将 其 设置 为 
nul， 比 如 t=nul。 那 么 这 个 ThreadLocal 对 应 的 所 有 线程 的 局 部 变量 都 
有 可 能 被 回收 。 这 里 面 的 奥秘 是 什么 呢 ? 先 来 看 一 个 徐 单 的 例子 : 


01 public class ThreadLocalDemo_Gc { 
02 static volatile ThreadLocal<SimpleDateFormat> tl = new 


ThreadLocal<SimpleDateFormat>() { 


03 protected void finalize() throws Throwable { 

04 System.out.println(this.toString() + " is gc"); 
05 } 

06 六 

07 static volatile CountDownLatch cd = new 


CountDownLatch(10000); 


08 public static class ParseDate implements Runnable { 
09 int i = 0; 

10 public ParseDate(int i) { 

11 this.i = 1; 


12 7 


13 public void run() { 


14 try { 
15 if (tl.get() == null) { 
16 tl.set(new SimpleDateFormat ("yyyy-MM-dd 


HH:mm:ss") { 

17 protected void finalize() throws 
Throwable { 

18 


System.out.printin(this.toString() + " is gc"); 


19 J 

20 }); 

21 

System.out.println(Thread.currentThread().getId() + £":create 


SimpleDateFormat"); 


22 } 

23 Date t = tl.get().parse("2015-03-29 19:29:" 
+ i % 60); 

24 } catch (ParseException e) { 

25 e.printStackTrace(); 

26 } finally { 

27 cd.countDown(); 

28 } 

29 } 

30 } 

Fe al 

32 public static void main(String[] args) throws 


InterruptedException { 


33 ExecutorService es = 


Executors.newFixedThreadPool(10); 


34 for (int i = 0; i < 10000; i++) { 

35 es.execute(new ParseDate(i)); 

36 f 

37 cd.await(); 

38 System.out.println("mission complete!!"); 
39 tl = null; 

40 System.gc(); 

41 System.out.println("first GC complete!!"); 
42 // 和 在 设置 ThreadLocal 的 时 候 ， 会 清除 ThreadLocalMap 中 的 无 效 对 
象 

43 tl = new ThreadLocal<SimpleDateFormat >(); 
44 cd = new CountDownLatch(10000) ; 

45 for (int i = 0; i < 10000; i++) { 

46 es.execute(new ParseDate(i)); 

47 } 

48 cd.await(); 

49 Thread.sleep(1000) ; 

50 System.gc(); 

51 System.out.println("second GC complete!!"); 
52 } 

beat 


上 述 案 例 是 为 了 跟 踩 ThreadLocal 对 象 以 及 内 部 SimpleDateFormat 
对 象 的 垃圾 回收 。 为 此 ， 我 们 在 第 3 行 和 第 17 行 ， 重 载 了 finalize() 方 
法 。 这 样 ， 我 们 在 对 象 被 回收 时 ， 束 可 以 看 到 它们 的 踪迹 。 


在 主 函 数 main 中 ， 先 后 进行 了 两 次 任务 提交 ， 每 次 10000 个 任务 。 
在 第 一 次 任务 提交 后 ， 代 码 第 39 行 ， 我 们 将 tl 设置 为 mull， 接 着 进行 一 
次 GC。 接 着 ， 我 们 进行 第 2 次 任务 提交 ， 完 成 后 ， 在 第 50 行 再 进行 一 
RGC ° 


如 果 你 执行 上 述 代码 ， 则 最 有 可 能 的 一 种 输出 如 下 : 


10:create SimpleDateFormat 
11:create SimpleDateFormat 
13:create SimpleDateFormat 
17:create SimpleDateFormat 
14:create SimpleDateFormat 
8:create SimpleDateFormat 
16:create SimpleDateFormat 
15:create SimpleDateFormat 
12:create SimpleDateFormat 
9:create SimpleDateFormat 
mission complete! ! 

first GC complete! ! 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$1@15f157b is gc 
9:create SimpleDateFormat 
8:create SimpleDateFormat 
16:create SimpleDateFormat 
13:create SimpleDateFormat 
15:create SimpleDateFormat 
10:create SimpleDateFormat 


11:create SimpleDateFormat 


14:create SimpleDateFormat 

17:create SimpleDateFormat 

12:create SimpleDateFormat 

second GC complete! ! 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 


geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 


主意 这 些 输出 所 代表 的 含义 。 首 和 完 ， 线 程 池 中 10 个 线程 都 各 目 创 
e 。 接 着 进行 第 一 次 GC， 可 以 看 到 
ThreadLocal 对 象 被 回收 了 (这 里 使 用 了 匿名 类 ， 所 以 类 名 看 起 来 有 点 
怪 ， 这 个 类 就 是 第 2 行 创建 的 tl 对 象 ，。 接 着 提交 了 第 2 次 任务 ， 这 次 
一 样 也 创建 了 10 个 SimpleDateFormat 对 象 。 然 后 ， 进 行 第 2 次 GC。 可 以 
看 到 ， 在 第 2 次 GC 后 ， 第 一 次 创建 的 10 个 SimpleDateFormat 子 类 实例 全 
部 被 回收 。 可 以 看 到 ， 虽 然 我 们 没有 手工 remove() 这 些 对 象 ， 但 是 系 
统 依然 有 可 能 回收 它们 (注意 ， 这 段 代码 是 在 JDK 7 中 输出 的 ， 在 JDK 
8 中 ， 你 也 许 得 不 到 类 似 的 输出 ， 大 家 可 以 比较 两 个 JDK 版 本 之 间 线 程 
持 有 ThreadLocal 变 量 的 不 同 ) 。 


要 了 解 这 里 的 回收 机 制 ， 我 们 需要 更 进一步 了 解 


一 AN 


个 类 似 HashMap 的 东西 。 更 精确 地 说 ， 它 更 加 类 似 WeakHashMap 。 


ThreadLocalMap 的 实现 使 用 了 弱 引 用 。 弱 引用 是 比 强 引 用 弱 得 多 
的 引用 。Java 虚 拟 机 在 垃圾 回收 时 ， 如 采 发 现 弱 引用 ， 束 会 立即 回 
收 。ThreadLocalMap 内 部 由 一 系列 Entry 构 成 ， 每 一 个 Entry 都 是 
WeakReference < ThreadLocal > : 


static class Entry extends WeakReference<ThreadLocal> { 
/** The value associated with this ThreadLocal. */ 
Object value; 
Entry(ThreadLocal k, Object v) { 
super(k); 


value = v; 


X BABS Ake Maplykey, vitizeMapAvalue ° Hkh ite 
ThreadLocal 实例 ， 作 为 弱 引 用 使 用 ( super(k) 就 是 调用 了 
WeakReferenceH #4) E HAL) 。 因 此 ， 虽 然 这 里 使 用 ThreadLocal 作 为 
Map 的 key， 但 是 实际 上 ， 它 并 不 真 的 持 有 ThreadLocal 的 引用 。 而 当 
ThreadLocal 的 外 部 强 引 用 被 回收 时 ，ThreadLocalMap 中 的 key 束 会 变 成 
null。 当 系统 进行 ThreadLocalMap 清 理 时 (比如 将 新 的 变量 加 入 表 中 ， 
束 会 自动 进行 一 次 清理 ， 虽 然 JDK 不 一 定 会 进行 一 次 彻底 的 扫描 ， 但 
显然 在 我 们 这 个 案例 中 ， 它 奏效 了 ) ， 束 会 自然 将 这 些 垃圾 数据 回 
收 。 整 个 结构 如 图 4.1 所 示 。 
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图 4.1 ”ThreadLocal 的 回收 机 制 


4.3.3 ”对 性 能 有 何 帮 助 


为 每 一 个 线程 分 配 一 个 独立 的 对 象 对 系统 性 能 也 许 是 有 帮助 的 。 
当然 了 ， 这 也 不 一 定 ， 这 完全 取决 于 共 至 对 象 的 内 部 逻辑 。 如 采 共 至 
对 和 象 对 于 竞争 的 处 理 容易 引起 性 能 损失 ， 我 们 还 是 应 该 考虑 使 用 
ThreadLocal 为 每 个 线程 分 配 单独 的 对 象 。 一 个 典型 的 案例 就 是 在 多 线 
程 下 产生 随机 数 。 


这 里 ， 让 我 们 简单 测试 一 下 在 多 线程 下 产生 随机 数 的 性 能 问题 。 
首先 ， 我 们 定义 一 些 全 局 变量 : 


01 public static final int GEN_COUNT = 10000000; 

02 public static final int THREAD_COUNT = 4; 

03 static ExecutorService exe = 
Executors.newFixedThreadPool(THREAD_COUNT ); 


04 public static Random rnd = new Random(123); 


05 
06 public static ThreadLocal<Random> tRnd = new ThreadLocal< 


Random>() { 


07 @Override 

08 protected Random initialValue() { 
09 return new Random(123); 

10 } 

11 }; 


代码 第 1 行 定义 了 每 个 线程 要 产生 的 随机 数 数 量 ， 第 2 行 定 义 了 参 
与 工作 的 线程 数量 ， 第 3 行 定 义 了 线程 池 ， 第 4 行 定 义 了 被 多 线程 共享 
的 Random 实 例 用 于 产生 随机 数 ， 第 6~11 行 定义 了 由 ThreadLocal 封 冯 
的 Random。 


接着 ， 定 义 一 个 工作 线程 的 内 部 逻辑 。 它 可 以 工作 在 两 种 模式 
下 : 


第 一 是 多 线程 共享 一 个 Random (mode=0) , 
第 二 是 多 个 线程 各 分 配 一 个 Random (mode=1) e 


01 public static class RndTask implements Callable<Long> { 


02 private int mode = 0; 

03 

04 public RndTask(int mode) { 
05 this.mode = mode; 

06 } 


07 


08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 


public Random getRandom() { 
if (mode == 0) { 
return rnd; 
} else if (mode == 1) { 
return tRnd.get(); 
} else { 


return null; 


@Override 
public Long call() { 
long b = System.currentTimeMillis(); 
for (long i = 0; i < GEN_COUNT; i++) { 
getRandom().nextInt(); 
} 
long e = System.currentTimeMillis(); 


System.out.printin(Thread.currentThread().getName() 


ro spene | i (@ =- D) ecu nies) ie 


26 
27 


return e - b; 
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最 后 是 我 们 的 main() 范 数 ， 它 分 别 对 上 述 两 种 情况 进行 测试 ， 并 
打印 了 测试 的 耗 时 : 


01 public static void main(String[] args) throws 


InterruptedException, ExecutionException { 


02 Future<Long>[] futs = new Future[THREAD_COUNT]; 

03 for (int i = 0; i < THREAD_COUNT; i++) { 

04 futs[i] = exe.submit(new RndTask(@)); 

05 } 

06 long totaltime = 0; 

07 for (int i = 0; i < THREAD_COUNT; i++) { 

08 totaltime += futs[i].get(); 

09 } 

10 System.out.println(" 多 线程 访问 同一 个 Random 实 例 :" + 


totaltime + "ms"); 


11 

12 //ThreadLocal 的 情况 

13 for (int 1 = 0; i < THREAD_COUNT; i++) { 

14 futs[i] = exe.submit(new RndTask(1)); 

15 } 

16 totaltime = 0; 

17 for (int i = 0; i < THREAD_COUNT; i++) { 

18 totaltime += futs[i].get(); 

19 } 

20 System.out.printin(" {€ FA ThreadLocal ® #2 Random ¥ ffi] :" + 


totaltime + "ms"); 


21 exe.shutdown(); 


22 } 
上 述 代 码 的 运行 结果 ， 可 能 如 下 : 


pool-1-thread-3 spend 3398ms 
pool-1-thread-1 spend 3436ms 
pool-1-thread-2 spend 3495ms 
pool-1-thread-4 spend 3513ms 
多 线程 访问 同一 个 Random 实 例 :13842ms 
pool-1-thread-4 spend 375ms 
pool-1-thread-1 spend 429ms 
pool-1-thread-2 spend 453ms 
pool-1-thread-3 spend 499ms 


使 用 ThreadLocal 包 装 Random 实 例 :1756ms 


很 明显 ， 在 多 线程 共享 一 个 Random 实 例 的 情况 下 ， 总 耗 时 达 13 秒 
之 多 〈 这 里 是 指 4 个 线程 的 耗 时 总 和 ， 不 是 程序 执行 的 经 历时 间 ) 。 而 
在 ThreadLocal 模 式 下 ， 仅 耗 时 1.7 秒 左右 。 


4.4 FR 


MAWRA, RITI hat RAR ADAIR o FR IRR 
说 ， 和 总 征 会 把 事情 往 好 的 方面 想 。 他 们 认为 所 有 事情 总 是 不 太 容 易 发 
生 问 题 ， 出 错 是 小 概率 的 ， 所 以 我 们 可 以 肆 无 忌 蛋 地 做 事 。 如 果真 的 
不 幸 遇 到 了 问题 ， 则 有 则 改 之 无 则 加 勉 。 而 对 于 翡 观 的 人 群 来 说 ， 他 
们 总 是 担 惊 受 旧 ， 认 为 出 错 是 一 种 常态 ， 所 以 无 论 巨 细 ， 都 考虑 得 面 
面 俱 到 ， 滴 水 不 漏 ， 确 保 为 人 处 世 ， 万 无 一 失 。 


对 于 并 发 控制 而 言 ， 锁 是 一 种 悲观 的 策略 。 它 总 是 假设 每 一 次 的 
AX BRED TR ESE, AL, DUT EERE EAB E o CURA 
多 个 线程 同时 需要 访问 临界 区 资源 ， 融 宁可 牺牲 性 能 让 线程 进行 等 
符 ， 所 以 说 锁 会 阻塞 线程 执行 。 而 无 锁 是 一 种 乐观 的 策略 ， 它 会 假设 
对 资源 的 访问 是 没有 冲突 的 。 既 然 没 有 冲突 ， 目 然 不 需要 等 待 ， 所 以 
所 有 的 线程 都 可 以 在 不 集 顿 的 状态 下 持续 执行 。 那 遇 到 冲突 怎么 办 
呢 ? 无 锁 的 策略 使 用 一 种 叫做 比较 交换 的 技术 (CAS Compare And 
Swap) 来 鉴别 线程 冲突 ， 一 旦 检测 到 冲突 产生 ， 束 重 试 当前 操作 直到 
没有 冲突 为 止 。 


4.4.1 与 众 不 同 的 并 发 策略 : 比较 交 
换 (CAS) 


与 锁 相 比 ， 使 用 比较 交换 (下 文 简称 CAS) 会 使 程序 看 起 来 更 加 
复杂 一 些 。 但 由 于 其 非 阻 塞 性 ， 它 对 死 锁 问题 天 生 人 免疫 并且， 线程 


间 的 相互 影响 也 远 远 比 基 于 锁 的 方式 要 小 。 更 为 重要 的 是 ， 使 用 无 锁 
的 方式 完全 没有 锁 竞 争 带 来 的 系统 开销 ， 也 没有 线程 间 频 和 党 调度 市 来 
的 开销 ， 因 此 ， 它 要 比 基 于 锁 的 方式 拥有 更 优越 的 性 能 。 


CAS 算 法 的 过 程 是 这 样 : 它 包含 三 个 参数 CAS(V,E,N)。V 表 示 要 
更 新 的 变量 ，E 表 示 预 期 值 ，N 表 示 新 值 。 仅 当 V 值 等 于 E 值 时 ， 才 会 
将 V 的 值 设 为 N， 如 果 V 值 和 E 值 不 同 ， 则 说 明 已 经 有 其 他 线程 做 了 更 
新 ， 则 当前 线程 什么 都 不 做 。 最 后 ，CAS 返 回 当 前 V 的 真实 值 。CAS 
操作 是 抱 着 乐观 的 态度 进行 的 ， 它 总 是 认为 自己 可 以 成 功 完 成 操作 © 
当 多 个 线程 同时 使 用 CAS 操 作 一 个 变量 时 ， 只 有 一 个 会 胜出 ， 并 成 功 
更 新 ， 其 余 均 会 失败 。 失 败 的 线程 不 会 被 挂 起 ， 仅 是 被 告知 失败 ， 并 
且 允 许 再 次 尝试 ， 当 然 也 允许 失败 的 线程 放弃 操作 。 基 于 这 样 的 原 
理 ，CAS 操 作 即 使 没有 锁 ， 也 可 以 发 现 其 他 线程 对 当前 线程 的 干扰 ， 
并 进行 恰当 的 处 理 。 


简单 地 说 ，CAS 需 要 你 额外 给 出 一 个 期 望 值 ， 也 融 是 你 认为 这 个 
变量 现在 应 该 是 什么 样子 的 。 如 采 变 量 不 是 你 想象 的 那样 ， 那 说 明 它 
已 经 被 别人 修改 过 了 。 你 束 重 新 读 取 ， 再 次 竹 试 修改 束 好 了 。 


在 硬件 层面 ， 大 部 分 的 现代 处 理 器 都 已 经 支持 原子 化 的 CAS 指 
Q ° JDK 5.0 以 后 ， 虚 拟 机 便 可 以 使 用 这 个 指令 来 实现 并 发 操作 和 并 
发 数据 结构 ， 并 且 ， 这 种 操作 在 虚拟 机 中 可 以 说 是 无 处 不 在 。 


442 无 锁 的 线程 安全 整数 : 


AtomicInteger 


为 了 让 Java 程 序 员 能 够 受益 于 CAS 等 CPU 指令 ，JDK 并 发 包 中 有 一 
个 atomic 包 ， 里 面 实 现 了 一 些 直接 使 用 CAS 操 作 的 线程 安全 的 类 型 。 


其 中 ， 最 第 用 的 一 个 类 ， 应 该 承 是 AtomicInteger。 你 可 以 把 它 看 


做 是 一 个 整数 。 但 是 与 nteger 不 同 ， 它 是 可 变 的 ， Ti E 


的 。 对 其 进行 修改 等 任何 操作 ， 都 是 用 CAS 指 令 进行 的 。 


o 


里 简单 列 


举 一 下 AtomicInteger 的 一 些 主要 方法 ， 对 于 其 他 原子 类 ， We 


党 类 似 的 : 


public final int get() 

前 值 

public final void set(int newValue) 

前 值 

public final int getAndSet(int newValue) 
值 ， 并 返回 旧 值 

public final boolean compareAndSet(int expect, int u) 
前 值 为 expect， 则 设置 为 u 

public final int getAndIncrement( ) 

加 1， 返 回 旧 值 

public final int getAndDecrement( ) 

减 1， 返 回 旧 值 

public final int getAndAdd(int delta) 
增加 delta， 返 回 旧 值 

public final int incrementAndGet() 

加 1， 返 回 新 值 

public final int decrementAndGet ( ) 

减 1， 返 回 新 值 


// 取 得 当 


// 设 置 当 


// 设 置 新 


// OR 


// 当 前 值 


// 当 前 值 


// 当 前 值 


// 当 前 值 


// 当 前 值 


public final int addAndGet(int delta) // 当 前 值 
增加 delta， 返 回 新 值 


就 内 部 实现 上 来 说 ，AtomicInteger 中 保存 一 个 核心 字段 : 
private volatile int value; 
它 束 代表 了 AtomicInteger 的 当前 实际 取 值 。 此 外 还 有 一 个 : 


private static final long valueOffset; 


它 你 存 着 value 字 上 段 在 AtomicInteger 对 象 中 的 偏 移 量 。 后 面 你 会 看 
到 ， 这 个 偏 移 量 是 实现 AtomicInteger 的 关键。 


AtomicInteger 的 使 用 非常 简单 ， 这 里 给 出 一 个 示例 ; 


01 public class AtomicIntegerDemo { 


02 static AtomicInteger i=new AtomicInteger(); 

03 public static class AddThread implements Runnable{ 

04 public void run(){ 

05 for(int k=0;k<10000; k++) 

06 1.incrementAndGet(); 

07 } 

08 } 

09 public static void main(String[] args) throws 


InterruptedException { 

10 Thread[] ts=new Thread[10]; 

11 for(int k=0;k<10;k++){ 

12 ts[k]=new Thread(new AddThread()); 


13 


14 for(int k=0;k<10;k++){ts[k].start();} 
15 for(int k=0;k<10;k++){ts[k].join();} 
16 System.out.println(1); 

17 } 

18 } 


第 6 行 的 AtomicIntegerincrementAndGet(0) 方 法 会 使 用 CAS 操 作 将 目 
己 加 1， 同 时 也 会 返回 当前 值 《这 里 忽略 了 当前 值 ) 。 如 果 你 执行 这 段 
代码 ， 你 会 看 到 程序 输出 了 100000。 这 说 明 程 序 正常 执行 ， 没 有 钳 
误 。 如 果 不 是 线程 安全 ，i 的 值 应 该 会 小 于 100000 才 对 。 


使 用 AtomicInteger 会 比 使 用 锁具 有 更 好 的 性 能 。 出 于 篇 幅 限 制 ， 
这 里 不 再 给 出 AtomicInteger 和 锁 的 性 能 对 比 的 测 斌 代码， 相信 写 一 上 段 
简单 的 小 代码 测试 两 者 的 性 能 应 该 不 是 难事 。 这 里 让 我 们 关注 一 下 
incrementAndGet() 的 内 部 实现 (我 们 基于 JDK 1.7 分 析 ，JDK 1.8 与 1.7 
的 实现 有 所 不 同 ) 。 


1 public final int incrementAndGet() { 

2 for (;;) { 

3 int current = get(); 

4 int next = current + 1; 

5 if (compareAndSet(current, next)) 
6 return next; 

7 

8 } 


其 中 get0 方 法 非常 简单 ， 就 是 返回 内 部 数据 value 。 


public final int get() { 


return value; 


这 里 让 人 映像 深刻 的 ， 应 该 是 incrementAndGet() 方 法 的 第 2 行 for 循 
环 吧 ! 如 有 果 你 是 初次 看 到 这 样 的 代码 ， 可 能 会 觉得 很 奇怪 ， 为 什么 连 
设置 一 个 值 那 么 简单 的 操作 都 需要 一 个 死 循环 呢 ? 原因 就 是 CASH 
作 未 必 是 成 功 的 ， 因 此 对 于 不 成 功 的 情况 ， 我 们 残 需要 进行 不 断 的 尝 
试 。 第 3 行 的 getO0 取 得 当前 值 ， 接 着 加 1 后 得 到 新 值 next。 这 里 ， 我 们 
束 得 到 了 CAS 必 需 的 两 个 参数 : 期 望 值 以 及 新 值 。 使 用 
compareAndSet() 方 法 将 狐 值 next 写 入 ， 成 功 的 条 件 是 在 写 入 的 时 刻 ， 
当前 的 值 应 该 要 等 于 刚刚 取得 的 current。 如果 不 是 这 样 ， 束 说 明 
AtomicInteger 的 值 在 第 3 行 到 第 5 行 代码 之 间 ， 又 被 其 他 线程 修改 过 
了 。 当 前 线程 看 到 的 状态 天 是 一 个 过 期 状态 。 因 此 ，compareAndSet 返 
回 失败 ， 需 要 进行 下 一 次 重 试 ， 直 到 成 功 。 


以 上 就 是 CAS 操 作 的 基本 思想 。 在 后 面 我们 会 看 到 ， 无 论 程 序 多 
LER, RESBAK EDEK ° 


和 AtomicInteger 类 似 的 类 还 有 AtomicLong 用 来 代表 long 型 , 
AtomicBoolean 表 示 boolean 型 ，AtomicReference 表 示 对 和 象 引 用 。 


4.4.3 Java PHJ}: Unsafe 类 


如 果 你 对 技术 有 着 不 折 不 搁 的 追求 ， 应 该 还 会 特别 在 意 
incrementAndGet() 方 法 中 compareAndSet() 的 实现 。 现 在 ， 束 让 我 们 更 
进一步 看 一 下 它 吧 ! 


public final boolean compareAndSet(int expect, int update) { 
return unsafe.compareAndSwapInt(this, valueOffset, expect, 

update); 

i 


在 这 里 ， 我 们 看 到 一 个 特殊 的 变量 unsafe， 它 是 sun.misc.Unsafe 类 
型 。 从 名 字 看 ， 这 个 类 应 该 是 封 狼 了 一 些 不 安全 的 操作 。 那 什么 操作 
是 不 安全 的 呢 ? 学 习 过 C 或 者 C++ 的 话 ， 大 家 应 该 知道 ， 指 针 是 不 安全 
的 ， 这 也 是 在 Java 中 把 指针 去 除 的 重要 原因 。 如 采 指 针 指 销 了 位 置 ， 
或 者 计算 指针 偏 移 量 时 出 错 ， 结 果 可 能 是 灾难 性 的 ， 你 很 有 可 能 会 履 
盖 别 人 的 内 存 ， 导 致 系统 朋 误 。 


而 这 里 的 Unsafe 就 是 封 效 了 一 些 类 似 指 针 的 操作 。 
compareAndSwapInt0 方 法 是 一 个 navtive 方 法 ， 它 的 几 个 参数 含义 如 
下 : 


public final native boolean compareAndSwapInt(Object o, long 


offset,int expected,int x); 


第 一 个 参数 o 为 给 定 的 对 象 ，offset 为 对 象 内 的 偏 移 量 (其 实 就 是 
一 个 字段 到 对 象 站 部 的 偏 移 量 ， 通 过 这 个 偏 移 量 可 以 快速 定位 字 
By) ，expected 表 示 期 望 值 ，x 表 示 要 设置 的 值 。 如 果 指 定 的 字段 的 值 
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不 难看 出 ，compareAndSwapInt() 方 法 的 内 部 ， 必 然 是 使 用 CAS 原 
子 指令 来 完成 的 。 此 外 ，Unsafe 类 还 提供 了 一 些 方法 ， 主 要 有 以 下 几 
个 (以 Int 操 作为 例 ， 其 他 数据 类 型 是 类 似 的 ) : 


// 获 得 给 定 对 象 偏 移 量 上 的 int 值 

public native int getInt(Object o, long offset); 

// 设 置 给 定 对 象 偏 移 量 上 的 ijnt 值 

public native void putInt(Object o, long offset, int x); 
// 获 得 字段 在 对 象 中 的 偏 移 量 
public native long objectFieldOffset(Field f); 

// 设 置 给 定 对 象 的 int 值 ， 使 用 volatile 语 义 

public native void putIntVolatile(Object o, long offset, int 


x); 

// 获 得 给 定 对 象 对 象 的 ijnt 值 ， 使 用 volatile 语 义 

public native int getIntVolatile(Object o, long offset); 
//AlputIntVolatile()—f#, (He CE BORRERET EcmievolatileR WH 
public native void putOrderediInt(Object o, long offset, int x); 


QUE K RIA 1 3.3.47 E HHT ConcurrentLinkedQueue” — 1 P fA 
述 的 ConcurrentLinkedQueue 实 现 ， 应 该 对 ConcurrentLinkedQueue 中 的 
Node 还 有 些 印象 。Node 的 一 些 CAS 操 作 也 都 是 使 用 Unsafe 类 来 实现 
的 。 大 家 可 以 回顾 一 下 ， 以 加 深 对 Unsafe 类 的 印象 。 


这 里 惑 可 以 看 到 ， 虽 然 Java 抛 弃 了 指针 。 但 是 在 关键 时 刻 ， 类 似 
指针 的 技术 还 是 必 不 可 少 的 。 这 里 底层 的 Unsafe 实 现 束 是 最 好 的 例 
子 。 但 是 很 不 笠 ，JDK 的 开发 人 员 并 不 希望 大 家 使 用 这 个 类 。 获 得 
Unsafe 实 例 的 方法 是 调动 其 工厂 方法 getUnsafe0。 但 是 ， 它 的 实现 却 
是 这 样 : 


public static Unsafe getUnsafe() { 
Class cc = Reflection.getCallerClass(); 


if (cc.getClassLoader() != null) 


throw new SecurityException("Unsafe"); 


return theUnsafe; 


注意 加 粗 部 分 的 代码 ， 它 会 检查 调用 getUnsafe() 函 数 的 类 ， 如 果 
这 个 类 的 ClassLoader 不 为 null， 残 直接 抛 出 异常 ， 拒 绝 工作 。 因 此 ， 
这 也 使 得 我 们 目 己 的 应 用 程序 无 法 直接 使 用 Unsafe 类 。 它 是 一 个 JDK 
内 部 使 用 的 专属 类 。 


TER: 根据 Java 类 加 载 器 的 工作 原理 ,应 用 程序 的 类 由 App 
Loader 加 载 。 而 系统 核心 类 ， 如 rt.jar 中 的 类 由 Bootstrap 类 加 载 絮 
加 载 。Bootstrap 加 载 絮 没有 Java 对 象 的 对 象 ， 因 此 试图 获得 这 个 
类 加 载 絮 会 返回 nul。 所 以 ， 当 一 个 类 的 类 加 载 右 为 hull 上 时， 说明 
它 是 由 Bootstrap 加 载 的 ， 而 这 个 类 也 极 有 可 能 是 rt.jar 中 的 类 。 


4.4.4 无 锁 的 对 象 引 用 : 


AtomicReference 


AtomicReference 和 AtomicInteger 非 常 类 似 ， 不 同 之 处 就 在 于 
AtomicInteger 是 对 整数 的 封装 ， 而 AtomicReference 则 对 应 普通 的 对 象 
引用 。 也 天 是 它 可 以 保证 你 在 修改 对 象 引 用 时 的 线程 安全 性 。 在 介绍 
AtomicReference 的 同时 ， 我 希望 同时 提出 一 个 有 关 原 子 操作 的 逻辑 上 
的 不 足 。 


之 前 我 们 说 过 ， 线 程 判 断 被 修改 对 象 是 否 可 以 正确 写 入 的 条 件 是 
对 和 象 的 当前 值 和 期 望 值 是 否 一 人 怪 。 这 个 逻辑 从 一 般 意义 上 来 说 是 正确 
的 。 但 有 可 能 出 现 一 个 小 小 的 例外 ， 吏 是 当 你 获得 对 象 当前 数据 后 ， 


在 准备 修改 为 新 值 前 ， 对 和 象 的 值 被 其 他 线程 连续 修改 了 两 次 ， 而 经 过 
这 两 次 修改 后 ， 对 和 象 的 值 又 恢复 为 旧 值 。 这 样 ， 当 前 线程 就 无 法 正确 
判断 这 个 对 象 完 竞 古 否 被 修改 过 。 如 图 4.2 所 示 ， 显 示 了 这 种 情况 。 
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图 4.2 ”对 象 值 被 反复 修改 回 原 数 据 


一 般 来 说 ， 发 生 这 种 情况 的 概率 很 小 。 而 且 即 使 发 生 了 ， 可 能 
不 是 什么 大 问题 。 比 如 ， 我 们 只 是 簿 单 地 要 做 一 个 数值 加 法 ， 即 使 在 
我 取得 期 望 值 后 ， 这 个 数字 被 不 断 的 修改 ， 只 要 它 最 终 改 回 了 我 的 期 
望 值 ， 我 的 加 法 计算 束 不 会 出 错 。 也 束 是 说 ， 当 你 修改 的 对 象 没有 过 
程 的 状态 信息 ， 所 有 的 信息 都 只 保存 于 对 象 的 数值 本 里 。 


但 是 ， 在 现实 中 ， 还 可 能 存在 男 外 一 种 场景 ， 就 是 我 们 是 否 能 修 
改 对 象 的 值 ， 不 仅 取 决 于 当前 值 ， 还 和 对 象 的 过 程 变化 有 关 ， 这 时 ， 
AtomicReference 束 无 能 为 力 了 。 


打 一 个 比方 ， 如 果 有 一 家 蛋糕 店 ， 为 了 挽留 客户 ， 决 定 为 贵宾 卡 
里 余额 小 于 20 元 的 客户 一 次 性 赠送 20 元 ， 刺 激 消 费 者 充值 和 消费 。 但 


条 件 是 ， 每 一 位 客户 只 能 被 赠送 一 次 。 


现在 ， 我 们 就 来 模拟 这 个 场景 ， 为 了 演示 AtomicReference ， 我 在 
这 里 使 用 AtomicReference 实 现 这 个 功能 。 首 先 ， 我 们 模拟 用 户 账户 余 
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定义 用 户 账户 余额 : 


static AtomicReference<Integer> money=new AtomicReference< 


Integer> (); 


// 设置 账户 初始 值 小 了 


money.set(19); 


2 


909， 显然 这 是 一 个 需要 被 充值 的 账户 


接着 ， 我 们 需要 者 干 个 后 全 线程 ， 它 们 不 断 扫描 数据 ， 并 为 满足 


条 件 的 客户 充值 。 


01 // 模 拟 多 个 线程 同时 更 新 后 台数 据 库 ， 为 用 户 充值 


02 Tete se is 0 p i < 3 p ikm) 


03 new Thread() { 

04 public void run() { 

05 while(true){ 

06 while(true){ 

07 Integer m=money.get(); 

08 if(m<20){ 

09 if(money.compareAndSet(m, m+20)){ 

10 System.out.printin("RAV)F207c, WMI, 


Ail: "+money.get()+"7t"); 


11 


break; 


12 
13 
14 
MICE" ) ; 
15 
16 
17 
18 
19 


i 
selse{ 


/VSystem,out,printLn(" 余 额 大 了 


break ; 


t 


20 }.start(); 


ea 


F2070, 无 


上 述 代 码 第 8 行 ， 判 断 用 户 余 额 并 给 予 赠送 金额 。 如 采 已 经 被 其 他 
用 户 处 理 ， 那 么 当前 线程 瑟 会 失败 。 因 此 ， 可 以 确保 用 户 只 会 被 充值 


— ye 0 


此 时 ， 如 果 很 不 垃 ， 用 户 正 好 正在 进行 消费 ， 融 在 赠 予 金额 到 账 


的 同时 ， 他 进行 了 


次 消费 ， 使 得 总 金额 又 小 于 20 元 ， 并 且 正 好 累计 


消费 了 20 元 。 使 得 消费 、 赠 予 后 的 金额 等 于 消费 前 、 赠 予 前 的 金额 。 
这 时 ， 后 台 的 赠 予 进程 束 会 误 以 为 这 个 账户 还 没有 赠 予 ， 所 以 ， 存 在 
被 多 次 赠 予 的 可 能 。 下 面 模拟 了 这 个 消费 线程 : 


01 // 用 户 消费 线程 ， 模 拟 消费 行为 
02 new Thread() { 


03 public void run() { 

04 for(int i=0;i<100;i++){ 

05 while(true){ 

06 Integer m=money.get(); 


07 if(m>10){ 


08 System.out.println("AF107c"); 
09 if (money.compareAndSet(m, m-10)){ 
10 System.out .println(" 成 功 消费 10 元 ， 祭 


额 ':"+money .get()); 


11 break; 

12 

13 }else{ 

14 System.out.printlLn(" 没 有 足够 的 金额 " ) ， 

15 break; 

16 } 

17 

18 try {Thread.sleep(100);} catch 


(InterruptedException e) {} 
19 i; 

20 } 

21 }.start(); 


上 述 代 码 中 ， 消 费 者 只 要 贵宾 卡 里 的 钱 大 于 10 元 ， 就 会 立即 进行 
一 次 10 元 的 消费 。 执 行 上 述 程序 ， 得 到 的 输出 如 下 : 


余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 


大 于 10 元 
成 功 消费 10 元 ， 人 余额 :29 
大 于 10 元 


成 功 消费 10 元 ， 人 余额:19 
余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 


大 于 10 元 

成 功 消费 10 元 ， 余 额 ;29 

大 于 10 元 

成 功 消 费 10 元 ， 余 额 ;39 
余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 


从 这 一 段 输出 中 ， 可 以 看 到 ， 这 个 账户 被 先后 反复 多 次 充值 。 其 
原因 正 古 因为 账户 余额 被 反复 修改 ， 修 改 后 的 值 等 于 原 有 的 数值 ， 使 
得 CAS 操 作 无 法 正确 判断 当前 数据 状态 。 


虽然 说 这 种 情况 出 现 的 概率 不 大 ， 但 是 依然 是 有 可 能 出 现 的 。 
此 ， 当 业务 上 确实 可 能 出 现 这 种 情况 时 ， 我 们 也 必须 多 加 防范 。 体 贴 
的 JDK 也 已 经 为 我 们 考虑 到 了 这 种 情况 ， 使 用 AtomicStampedReference 
瓯 可 以 很 好 地 解决 这 个 问题 。 


4.4.5 珊 有 时 间 玲 的 对 象 引 用 : 


AtomicStampedReference 


AtomicReference 无 法 解决 上 述 问 题 的 根本 因为 是 对 象 在 修改 过 程 
中 ， 丢 失 了 状态 信息 。 对 象 值 本 身 与 状态 被 画 上 了 等 号 。 因 此 ， 我 们 
只 要 能 够 记录 对 象 在 修改 过 程 中 的 状态 值 ， 就 可 以 很 好 地 解决 对 象 被 
反复 修改 导致 线程 无 法 正确 判断 对 象 状 态 的 问题 。 


AtomicStampedReference 正 是 这 么 做 的 。 它 内 部 不 仅 维护 了 对 和 象 
值 ， 还 维护 了 一 个 时 间 戳 〈 我 这 里 把 它 称 为 时 间 戳 ， 实 际 上 它 可 以 使 
任何 一 个 整数 来 表示 状态 值 ) 。 当 AtomicStampedReference 对 应 的 数 
值 被 修改 上 时， 除了 更 新 数据 本 里 外 ， 还 必须 要 更 新 时 间 稚 。 当 


AtomicStampedReference 设 置 对 象 值 时 ， 对 象 值 以 及 时 间 稚 都 必须 满 
足 期 望 值 ， 写 入 才 会 成 功 。 因 此 ， 即 使 对 象 值 被 反复 读 写 ， 写 回 原 
值 ， 只 要 时 间 玲 发 生变 化 ， 束 能 防止 不 恰当 的 写 入 。 


AtomicStampedReference 的 儿 个 API 在 AtomicReference 的 基础 上 新 
增 了 有 关 时 间 惟 的 信息 : 


// 比 较 设 置 参数 依次 为 : 期 望 值 SADE 期 望 时 间 稚 S EER 


public boolean compareAndSet(V expectedReference, V 


newReference, int expectedStamp, int newStamp) 
// 获 得 当前 对 象 引 用 

public V getReference() 

/ / 5X4 BURT ALY 

public int getStamp() 

// 15 BUT ARS | FA AES Te 


public void set(V newReference, int newStamp) 


有 了 AtomicStampedReference 这 个 法 宝 ， 我 们 就 再 也 不 用 担心 对 
RA SUM! 现在 ， 束 让 我 们 使 用 AtomicStampedReference 来 修正 那 
个 贵宾 卡 充 值 的 问题 : 


01 public class AtomicStampedReferenceDemo { 
02 Static AtomicStampedReference< Integer > money=new 


AtomicStampedReference< Integer > (19,0); 


03 public static void main(String[] args) { 
04 // 模 拟 多 个 线程 同时 更 新 后 人 台数 据 库 ， 为 用 户 充 值 
05 POR (CEM a> Se Oy So a Se eee it 


06 final int timestamp=money.getStamp(); 


07 
08 
09 
10 
11 
12 
13 


new Thread() { 
public void run() { 
while(true) { 
while(true) { 
Integer m=money.getReference(); 
if (m<20)£ 


if (money .compareAndSet(m, 


m+20, timestamp, timestamp+1) ) { 


14 


System.out.println("RM/) F207, Ri, R 


Ail: "+money.getReference()+"7c"); 


15 
16 
17 
18 


19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 


break; 
} 
yelse{ 
//System,out,printlLn(" 余 额 大 


F2070, FAIRE"); 


break ; 


} 
}.start(); 


// 用 户 消费 线程 ， 模 拟 消费 行为 
new Thread() { 


public void run() { 


for(int 1=0;1<100;i++){ 


31 while(true) { 


32 int timestamp=money.getStamp(); 

33 Integer m=money .getReference(); 

34 if(m>10){ 

35 System,out,.printLn(" 大 于 10 元 ") ， 
36 if(money.compareAndSet(m, m- 


10, timestamp, timestamp+1) ) { 


37 System.out.println("AKAw #107, R 


Ail: "+money.getReference()); 

38 break; 

39 } 

40 yelse{ 

41 System.out.println(" 没 有 足够 的 金 
ail"); 


42 break; 


st 


43 } 
44 } 
45 try {Thread.sleep(100);} catch 


(InterruptedException e) {} 


46 } 
47 } 

48 }.start(); 
49 } 

50 } 


第 2 行 ， 我 们 使 用 AtomicStampedReference 代替 原来 的 
AtomicReference。 第 6 行 获 得 账户 的 时 间 戳 ， 后 续 的 赠 予 操作 以 这 个 


时 间 戳 为 依据 。 如 果 赠 予 成 功 〈 第 13 行 ) ， 则 修改 时 间 戳 ， 使 得 系统 
不 可 能 发 生 二 次 赠 予 的 情况 。 消 费 线程 也 是 类 似 ， 每 次 操作 ， 都 使 得 
时 间 戳 加 1 (第 36 行 ， 使 之 不 可 能 重复 。 


执行 上 述 代码 ， 可 以 得 到 以 下 输出 : 


余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 


大 于 10 元 

成 功 消 费 16 元 ， 余 额 :29 
大 于 10 元 

成 功 消费 10 元 ， 余 额 :19 
大 于 10 元 

成 功 消费 10 元 ， 余 额 :9 
没有 足够 的 金额 


可 以 看 到 ， 账 户 只 被 赠 巴 了 一 次 。 


4.4.6 数组 也 能 无 锁 : 


AtomicIntegerArray 


除了 提供 基本 数据 类 型 外 ，JDK 还 为 我 们 准备 了 数组 等 复合 结 
构 。 当 前 可 用 的 原子 数组 有 : AtomicIntegerArray ` AtomicLongArray 
和 AtomicReferenceArray， 分 别 表示 整数 数组 、long 型 数组 和 普通 的 对 
象 数组 。 


这 里 以 AtomicIntegerArray 为 例 ， 展 示 原 子 数 组 的 使 用 方式 。 


AtomicImntegerArray 本 质 上 是 对 int[] 类 型 的 封装 ， 使 用 Unsafe 类 通 
过 CAS 的 方式 控制 int[] 在 多 线程 下 的 安全 性 。 它 提供 了 以 下 几 个 核心 
API: 


// 获 得 数组 第 i 个 下 标的 元 素 

public final int get(int i) 

// 获 得 数组 的 长 度 

public final int length() 

// 将 数组 第 i 个 下 标 设置 为 newValue， 并 返回 旧 的 值 

public final int getAndSet(int i, int newValue) 

// 进 行 CAS 操 作 ， 如 果 第 i 个 下 标的 元 素 等 于 expect， 则 设置 为 update， 设 置 成 功 返 
回 true 


public final boolean compareAndSet(int i, int expect, int 
update) 

// 将 第 i 个 下 标的 元 素 加 1 

public final int getAndIncrement(int i) 

// 将 第 i 个 下 标的 元 素 减 1 

public final int getAndDecrement(int i) 

// 将 第 i 个 下 标的 元 素 增加 delta (delta 可 以 是 负数 ) 

public final int getAndAdd(int i, int delta) 


下 面 给 出 一 个 简单 的 示例 ， 展 示 AtomicIntegerArray 的 使 用 : 


01 public class AtomicIntegerArrayDemo { 

02 Static AtomicIntegerArray arr = new 
AtomicIntegerArray(10); 

03 public static class AddThread implements Runnable{ 


04 public void run(){ 


05 for(int k=0;k<10000; k++) 


06 arr.getAndIncrement(k%arr.length()); 

07 } 

08 } 

09 public static void main(String[] args) throws 


InterruptedException { 


10 Thread[] ts=new Thread[10]; 

11 for(int k=0;k<10;k++){ 

12 ts[k]=new Thread(new AddThread()); 
13 } 

14 for(int k=0;k<10;k++){ts[k].start();} 
15 for(int k=0;k<10;k++){ts[k].join();} 
16 System.out.println(arr); 

17 } 

18 } 


上 述 代 码 第 2 行 ， 申 明了 一 个 内 含 10 个 元 素 的 数组 。 第 3 行 定义 的 
线程 对 数组 内 10 个 元 素 进行 累加 操作 ， 每 个 元 素 各 加 1000 次 。 第 11 
行 ， 开 启 10 个 这 样 的 线程 。 因 此 ， 可 以 预测 ， 如 果 线 程 安全 ， 数 组 内 
10 个 元 素 的 值 必 然 都 是 10000。 反 之 ， 如 果 线 程 不 安全 ， 则 部 分 或 者 全 
部 数值 会 小 于 10000 。 


程序 的 输出 结果 如 下 : 


[10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 
10000] 


这 说 明 AtomicIntegerArray 确 实 合理 地 保证 了 数组 的 线程 安全 性 。 


44.7 ”让 普通 变量 也 享受 原子 操作 : 


AtomicIntegerFieldUpdater 


有 时 候 ， 由 于 初期 考虑 不 周 ， 或 者 后 期 的 需求 变化 ， 一 些 普 通 变 
量 可 能 也 会 有 线程 安全 的 需求 。 如 有 果 改 动 不 大 ， 我 们 可 以 简单 地 修改 
a Aa 但 显然 ， 这 样 并 不 符合 
软件 设计 中 的 一 条 开 闭 原则 。 也 就 是 系统 对 功能 的 增加 
应 该 是 开放 的 ， ee 而 且 ， 如 采 系 统 里 使 用 
到 这 个 变量 的 地 方 特别 多 ， 一 个 一 个 修改 也 是 一 件 令 人 厌烦 的 事情 
(况且 很 多 使 用 场景 下 可 能 只 是 只 读 的 ， 并 无 线程 安全 的 强烈 要 求 ， 
完全 可 以 保持 原样 ) 


如 果 你 有 这 种 困扰 ， 在 这 里 根本 不 需要 担心 ， 因 为 在 原子 包 里 还 
有 一 个 实用 的 工具 de ear eget ae 它 可 以 让 你 在 不 改动 
(或 者 极 少 改动 ) 原 有 代码 的 基础 上 ， 让 普通 的 变量 也 享受 CAS 操 作 
带 来 的 线程 安全 性 ， econ te 来 获得 线程 安全 的 
傈 证。 这 上 听 起 来 是 不 是 让 人 很 激动 呢 ? 


根据 数据 类 型 不 同 ， 这 个 Updater 有 三 种 ， 2 All ze 
AtomicIntegerFieldUpdater à PN FieldUpdater ”和 
AtomicReferenceFieldUpdater。 顾 名 思 义 ， 它 们 分 别 可 以 对 int、long 和 
普通 对 象 进 行 CAS 修 改 。 


现在 来 思考 这 么 一 个 场景 。 假 设 某 地 要 进行 一 次 选举 。 现 在 oe 
XT, MRR TRA, MWENL, FIENO » 
RAE AD ze PTB BOY ta] LOK o 


01 public class AtomicIntegerFieldUpdaterDemo { 


02 public static class Candidate{ 

03 int id; 

04 volatile int score; 

05 } 

06 public final static AtomicIntegerFieldUpdater <Candidate 


> scoreUpdater 
07 = 
AtomicIntegerFieldUpdater .newUpdater(Candidate.class, "score"); 


08 // 检 查 Updater 是 否 工作 正确 


09 public static AtomicInteger allScore=new 
AtomicInteger(0); 
10 public static void main(String[] args) throws 


InterruptedException { 


11 final Candidate stu=new Candidate(); 

12 Thread[] t=new Thread[10000]; 

iL®@ for(int i = 0 ; i < 10000 ; i++) { 

14 t[i]=new Thread() { 

15 public void run() { 

16 if(Math.random()>0.4){ 

17 scoreUpdater.incrementAndGet (stu); 
18 allScore.incrementAndGet(); 
19 Í 

20 } 

21 }; 

22 t[i].start(); 


23 } 


24 for(int i = 0 ; i < 10000 ; i++) { t[i].join();} 


25 System.out.println("score="+stu.score); 
26 System.out.println("allScore="+allScore); 
27 } 

28 } 


上 述 代 码 模拟 了 这 个 计 票 场景 ， 候 选 人 的 得 票数 量 记录 在 
Candidate.score 中 。 注 意 ， 它 是 一 个 普通 的 volatile 变 量 。 而 volatile 变 量 
并 不 是 线程 安全 的 。 第 6 一 7 行 定 义 了 AtomicIntegerFieldUpdater 实 例 ， 
用 来 对 Candidate.score 进 行 写 入 。 而 后 续 的 alScore 我 们 用 来 检查 
AtomicIntegerFieldUpdater 的 正确 性 。 如 果 AtomicIntegerFieldUpdater 真 
的 保证 了 线程 安 人 全， 那么 最 终 Candidate.score 和 allScore 的 值 必然 是 相 
等 的 。 否 则 ， 就 说 明 AtomicIntegerFieldUpdater 根 本 没有 确保 线程 安全 
的 写 入 。 第 12 一 21 行 模拟 了 计 票 过 程 ， 这 里 假设 有 大 约 60% 的 人 投 赞 
成 票 ， 并 且 投 票 是 随机 进行 的 。 第 17 行 使 用 Updater 修改 
Candidate.score (这 里 应 该 是 线程 安全 的 ) ， 第 18 行 使 用 AtomicInteger 
计数 ， 作 为 参考 基准 。 


大 家 如 果 运 行 这 段 程 序 ， 不 难 发 现 ， 最 终 的 Candidate.score 总 是 和 
allScore 绝 对 相等 。 这 说 明 AtomicIntegerFieldUpdater 很 好 地 保证 了 
Candidate.score 的 线程 安全 。 


虽然 AtomicIntegerFieldUpdater 很 好 用 ， 但 是 还 是 有 几 个 注意 事 


第 一 ，Updater 只 能 修改 它 可 见 范 围 内 的 变量 。 因 为 Updater 使 用 反 
喘 得 到 这 个 变量 。 如 有 果 变 量 不 可 见 ， 束 会 出 错 。 比 如 如 果 score 申 明 为 
private， 就 是 不 可 行 的 。 


第 二 ， 为 了 确保 变量 被 正确 的 读 取 ， 它 必须 古 volatile 类 型 的 。 如 
果 我 们 原 有 代码 中 未 申明 这 个 类 型 ， 那 么 位 单 地 申明 一 下 就 行 ， 这 不 
会 引起 什么 问题 。 


第 三 a A 
I, , ER 支持 static 字 段 (Unsafe. objectFieldOffsetO 不 支持 静态 变 
量 ) 

好 了 ， 通 过 AtomicIntegerFieldUpdater， 是 不 是 让 我 们 可 以 更 加 随 
心 所 欲 地 对 系统 关键 数 据 进行 线程 安全 的 保护 呢 ? 


4.4.8 ”挑战 无 锁 算 法 无 锁 的 Vector 
实现 


我 们 已 经 比较 完整 地 介绍 了 有 关 无 锁 的 概念 和 使 用 方法 。 相 对 于 
有 锁 的 方法 ， 使 用 无 锁 的 方式 编程 更 加 考验 一 个 程序 员 的 耐心 和 先 
力 。 但 是 ， 无 锁 市 来 的 好 处 也 是 显而易见 的 ， 第 一 ， 在 高 并 发 的 情况 
下 ， 它 比 有 锁 的 程序 拥有 更 好 的 性 能 ， 第 二 ， 它 天 生 就 是 死 锁 免 疫 
的 。 就 凭借 这 两 个 优势 ， 束 值得 我 们 旱 险 笑 试 使 用 无 锁 的 并 发 。 


这 里 ， 我 想 癌 大 家 介绍 一 种 使 用 无 锁 方 式 实现 的 Vector。 通 过 这 
个 案例 ， 我 们 可 以 更 加 深刻 地 认识 无 锁 的 算法 ， 同 时 也 可 以 学 习 一 下 
有 关 Vector 实 现 的 细节 和 算法 技巧 (在 本 例 中 ， 讲 述 的 无 锁 Vector 来 自 
于 amino 并 发 包 ) ° 


我 们 将 这 个 无 锁 的 Vector 称 为 LockEreeVector 。 它 的 特点 是 可 以 根 
据 需求 动态 扩展 其 内 部 空间 。 在 这 里 ， 我 们 使 用 二 维 数 组 来 表示 


LockFreeVector 的 内 部 存储 ， 如 下 : 


private final AtomicReferenceArray<AtomicReferenceArray<E> > 


buckets; 


变量 buckets 存 放 所 有 的 内 部 元 素 。 从 定义 上 看 ， 它 是 一 个 保存 着 
数组 的 数组 ， 也 就 是 通常 的 二 维 数组 。 特 别 之 处 在 于 这 些 数 组 都 是 使 
用 CAS 的 原子 数组 。 为 什么 使 用 二 维 数组 去 实现 一 个 一 维 的 Vector 
WE? 这 是 为 了 将 来 Vector 进行 动态 扩展 时 可 以 更 加 方便 。 我 们 知道 ， 
AtomicReferenceArray 内 部 使 用 Object[] 来 进行 实际 数据 的 存储 ， 这 使 
得 动态 空间 增加 特别 的 麻烦 ， 因 此 使 用 二 维 数组 的 好 处 就 是 为 了 将 来 
可 以 方便 地 增加 新 的 元 素 。 


此 外 ， 为 了 更 有 序 的 读 写 数组 ， 定 义 一 个 称 为 Descriptor 的 元 巡 。 
它 的 作用 是 使 用 CAS 操 作 写 入 新 数据 。 


01 static class Descriptor<E> { 


02 public int size; 

03 volatile WriteDescriptor<E> writeop; 

04 public Descriptor(int size, WriteDescriptor<E> writeop) 
{ 

05 this.size = size; 

06 this.writeop = writeop; 

07 } 

08 public void completeWrite() { 

09 WriteDescriptor<E> tmpop = writeop; 

10 if (tmpop != null) { 


11 tmpOp.doIt(); 


12 writeop = null; // this is safe since all write 
to writeop use 

13 // null as r_value. 

14 } 

15 } 

16 } 

17 


18 static class WriteDescriptor<E> { 


19 public E oldV; 

20 public E newV; 

21 public AtomicReferenceArray<E> addr; 

22 public int addr_ind; 

23 

24 public WriteDescriptor(AtomicReferenceArray<E> addr, 


int addr_ind, 


25 E oldV, E newV) { 

26 this.addr = addr; 

27 this.addr_ind = addr_ind; 

28 this.oldV = oldV; 

29 this.newV = newV; 

30 } 

31 

32 public void doIt() { 

33 addr .compareAndSet(addr_ind, oldV, newV); 
34 } 


上 述 代 码 第 4 行 定义 的 Descriptor 构 造 男 数 接收 两 个 参数 ， 第 一 个 
为 整个 Vector 的 长 度 ， 第 2 个 为 一 个 writer。 最 终 ， 写 入 数据 是 通过 
writer 进 行 的 (通过 completeWrite() 方 法 ) ° 


第 24 行 ，WriteDescriptor 的 构造 男 数 接收 四 个 参数 。 第 一 个 参数 
addr 表 示 要 修改 的 原子 数组 ， 第 二 个 参数 为 要 写 入 的 数组 索引 位 置 ， 
第 三 个 oldV 为 期 望 值 ， 第 四 个 newV 为 需要 写 入 的 值 。 


在 构造 LockFreeVector 时 ， 显 然 需要 将 buckets 和 descriptor 进 行 初 始 
化 。 


public LockFreeVector() { 
buckets = new AtomicReferenceArray<AtomicReferenceArray<E 
> >(N_BUCKET); 
buckets.set(0, new AtomicReferenceArray <E> 
(FIRST_BUCKET_SIZE) ); 
descriptor = new AtomicReference<Descriptor <E> > (new 
Descriptor<E>(0, 


null)); 


在 这 里 N_BUCKET 为 30, 也 就 是 说 这 个 buckets 里 面 可 以 存放 一 共 30 
个 数组 (由 于 数组 无 法 动态 增长 ， 因 此 数组 总 数 也 就 不 能 超过 30 
个 ) 。 并 且 将 第 一 个 数组 的 大 小 FIRST_BUCKET_SIZE 设 为 8。 到 这 
里 ， 大 家 可 能 会 有 一 个 疑问 ， 如 果 每 个 数组 8 个 元 素 ， 一 共 30 个 数组 ， 
那 岂 不 是 一 共 只 能 存放 240 个 元 素 吗 ? 


如 果 大 家 了 解 JDK 内 的 Vector 实现 ， 应 该 知道 ， Vcore 
增长 时 ， 默 认 情 况 下 ， 每 次 都 会 将 总 容量 翻 倍 。 因 此 ， 这 里 也 借鉴 类 
似 的 思想 ， 每 次 空间 扩张 ， 新 的 数组 的 大 小 为 原来 的 两 倍 ( 即 每 次 空 
IS 展 都 局 用 一 个 人 新 的 数组 ) ， 因 此 ， 第 一 个 数组 为 8， 第 二 个 就 是 
16， 第 三 个 就 是 32。 依 此 类 推 ， 因 此 30 个 数组 可 以 支持 的 总 元 素 达 到 


-96 o 


这 数值 已 经 超过 了 2A33， 即 在 80 亿 以 上 。 因 此 ， 可 以 满足 一 般 的 
MvH e 


当 有 元 素 需 要 加 入 LockFreeVector 时 ， 使 用 pe 为 push_back() 的 
方法 ， 将 元 素 压 入 Vector 最 后 一 个 位 置 。 这 个 操作 显然 就 是 
LockFreeVector 的 最 为 核心 的 方法 ， 也 是 最 能 ere 使 用 特点 的 方 
法 ， 它 的 实现 如 下 : 


01 public void push_back(E e) { 


02 Descriptor<E> desc; 

03 Descriptor<E> newd; 

04 do { 

05 desc = descriptor.get(); 

06 desc.completeWrite(); 

07 

08 int pos = desc.size + FIRST_BUCKET_SIZE; 

09 int zeroNumPos = Integer.numberOfLeadingZeros(pos); 
10 int bucketInd = zeroNumFirst - zeroNumPos; 

11 if (buckets.get(bucketInd) == null) { 

12 int newLen = 2 * buckets.get(bucketInd - 


1).length(); 


13 if (debug) 


14 System.out.printin("New Length is:" + 
newLen); 

15 buckets.compareAndSet(bucketInd, null, 

16 new AtomicReferenceArray<E>(newLen) ); 
17 } 

18 

19 int idx = (0x80000000>>->zeroNumPos) ^ pos; 

20 newd = new Descriptor<E>(desc.size + 1, new 


WriteDescriptor <E > ( 


21 buckets.get(bucketInd), idx, null, e)); 
22 } while (!descriptor.compareAndSet(desc, newd)); 

23 descriptor.get().completewrite(); 

24 } 
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全 性 。 在 第 23 行 ， 使 用 descriptor 将 数据 真正 地 写 入 数组 中 。 这 个 
descriptor 写 入 的 数据 由 第 20~21 行 构造 的 WriteDescriptor 决 定 。 


在 循环 最 开始 (517) ， 使 用 descriptor 先 将 数据 写 入 数组 ， 是 为 
了 防止 上 一 个 线程 设置 完 descriptor 后 〈 第 22 行 ) ， 还 没 来 得 及 执行 第 
23 行 的 写 入 ， 因 此 ， 做 一 次 预防 性 的 操作 。 


因为 限制 要 将 元 素 e 压 入 Vector， 因 此 ， 我 们 必须 站 先 知道 这 个 e 应 
该 放 在 哪个 位 置 。 由 于 目前 使 用 了 二 维 数 组 ， 因 此 我 们 自然 需要 知道 
所 在 哪个 数组 (buckets 中 的 下 标 位 置 ) 和 数组 中 的 下 标 。 


第 8 一 10 行 通过 当前 Vector 的 大 小 (desc.size) ， 计 算 新 的 元 素 应 
该 落 入 哪个 数组 。 这 里 使 用 了 位 运算 进行 计算 。 


之 前 说 过 ，LockFreeVector 每 次 都 会 成 倍 的 扩容 。 它 的 第 1 个 数组 
长 度 为 8， 第 2 个 整 是 16， 第 3 个 就 是 32， 依 此 类 推 。 它 们 的 二 进 制 表示 
如 下 。 


e 00000000 00000000 00000000 00001000: 第 一 个 数组 大 小 ，28 
个 前 导 零 。 
e 00000000 00000000 00000000 00010000: 第 二 个 数组 大 小 ，27 
个 前 导 零 。 
。 00000000 00000000 00000000 00100000: 第 三 个 数组 大 小 ，26 
AN Ee 
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e 00000000 00000000 00000000 01000000: 第 四 个 数组 大 小 ，25 
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它们 之 和 就 是 整个 LockFreeVector 的 总 大 小 ， 因 此 ， 如 果 每 一 个 数 
组 都 恰好 填 满 ， 那 么 总 大 小 应 该 类 似 如 下 的 数值 (以 4 个 数组 填 满 为 
例 ) 。 


e 00000000 00000000 00000000 01111000: 4 个 数组 都 恰好 填 满 时 
的 大 小 。 


导致 这 个 数字 进位 的 最 小 条 件 ， 束 是 加 上 二 进 制 的 1000。 而 这 个 
数字 正好 是 8 (FIRST_BUCKET_SIZE 就 是 8) 。 这 就 是 第 8 行 代 码 的 意 
义 。 它 可 以 使 得 数组 大 小 发 生 一 次 二 进 制 的 进位 (如果 不 进位 说 明 还 
在 第 一 个 数组 中 ) ， 进 位 后 前 导 零 的 数量 就 会 发 生变 化 。 而 元 素 所 在 
的 数组 ， 和 pos (第 8 行 定 义 的 变量 ) 的 前 导 零 直接 相关 。 每 进行 一 次 


数组 扩容 ， 它 的 前 导 零 就 会 减 1° 如 果 从 来 没有 扩容 过 ， 它 的 前 导 零 就 
是 28 个 。 以 后 ， 了 未 级 减 1°。 这 就 是 第 9 行 获得 pos 前 导 零 的 原因 。 第 10 
行 ， 通 过 pos 的 前 导 零 可 以 立即 定位 使 用 哪个 数组 《也 就 是 得 到 了 
bucketInd 的 值 ) 。 


第 11 行 ， 判 断 这 个 数组 是 否 存在 。 如 采 不 存在 ， 则 创建 这 个 数 
组 ， 大 小 为 前 一 个 数组 的 两 倍 ， 并 把 它 设置 到 buckets 中 。 


接着 再 看 一 下 元 素 没有 恰好 填 满 的 情况 。 


。 00000000 00000000 00000000 00001000: 第 一 个 数组 大 小 ，28 
个 前 导 零 。 

。 00000000 00000000 00000000 00010000: 第 二 个 数组 大 小 ，27 
个 前 导 零 。 

。 00000000 00000000 00000000 00100000: 第 三 个 数组 大 小 ，26 
个 前 导 零 。 

e 00000000 00000000 00000000 00000001: 第 四 个 数组 大 小 ， 只 
eel Ww ee 


那么 总 大 小 如 下 。 
。 00000000 00000000 00000000 00111001: 元 素 总 个 数 。 
总 个 数 加 上 二 进 制 1000 后 ， 得 到 ; 


。 00000000 00000000 00000000 01000001 


显然 ， 通 过 前 导 零 可 以 定位 到 第 4 个 数组 。 而 剩余 位 ， 显 然 就 表示 
元 素 在 当前 数组 内 的 偏 移 量 (也 就 是 数组 下 标 ) 。 根 据 这 个 理论 ， 我 
们 融 可 以 通过 pos 计 算 这 个 元 素 应 该 放 在 给 定数 组 的 哪个 位 置 。 通 过 第 


19 行 代码 ， 获 得 pos 的 除了 第 一 位 数字 1 以 外 的 其 他 位 的 数值 。 因 此 ， 
pos 的 前 导 零 可 以 表示 元 素 所 在 的 数组 ， 而 pos 的 后 面 儿 位 ， 则 表示 元 
素 所 在 这 个 数组 中 的 位 置 。 由 此 ， 第 19 行 代码 就 取得 了 元 素 的 所 在 位 
置 idx。 


到 此 ， 我 们 束 已 经 得 到 新 元 闵 位 置 的 全 部 信息 ， 剩 下 的 就 是 将 
些 信息 传递 给 Descriptor 让 它 在 给 定 的 位 置 把 元 素 e 安 置 上 去 即 可 。 
里 ， 束 通过 CAS 操 作 ， 保 证 写 入 正确 性 。 


这 
这 


下 面 来 看 一 下 get() 操 作 的 实现 : 


1 @Override 


2 public E get(int index) { 


3 int pos = index + FIRST_BUCKET_SIZE; 

4 int zeroNumPos = Integer.numberOfLeadingZeros(pos); 
5 int bucketInd = zeroNumFirst - zeroNumPos; 

6 int idx = (0x80000000>>->zeroNumPos) ^ pos; 

7 return buckets.get(bucketInd).get(idx); 

8 } 


在 get0 的 实现 中 ， 第 3~6 行 使 用 了 相同 的 算法 获得 所 需 元 素 的 数 
组 以 及 数组 中 的 索引 下 标 。 这 里 简单 地 通过 buckets 定 位 到 对 应 的 元 素 
BURY ° 


这 样 ， 对 于 Vector 来 说 两 个 重要 的 方法 融 已 经 实现 了 。 其 他 方法 
也 是 非常 类 似 的 ， 这 里 就 不 再 详细 讨论 了 。 


449 ”让 线程 之 间 互 相 帮 助 : 细 看 
SynchronousQueue 的 实现 


在 对 线程 池 的 介绍 中 ， 提 到 了 一 个 非常 特殊 的 等 每 队列 
SynchronousQueue ° SynchronousQueue 的 容量 为 0， 任 何 一 个 对 
SynchronousQueue 的 写 需 要 等 竺 一 个 对 SynchronousQueue 的 读 ， 反 之 
亦 然 。 因 此 ，SynchronousQueue 与 其 说 是 一 个 队列 ， 不 如 说 是 一 个 数 
据 交 换 通 道 。 那 SynchronousQueue 的 奇妙 功能 是 如 何 实现 的 呢 ? 


既然 我 打算 在 这 一 万 中 介绍 它 ， 那 么 SynchronousQueue 就 和 无 锁 
的 操作 脱离 不 了 关系 。 实 际 上 SynchronousQueue 内 部 也 正 是 大 量 使 用 
TEMLE ° 


对 SynchronousQueue 来 说 ， 它 将 put0 和 take0 两 个 功能 截然 不 同 的 
操作 抽象 为 一 个 共通 的 方法 Transferer.transfer0。 从 字面 上 看 ， 这 如 是 
数据 传递 的 意思 。 它 的 完整 签名 如 下 : 


Object transfer(Object e, boolean timed, long nanos) 


当 参 数 e 为 非 空 时 ， 表 示 当 前 操作 传递 给 一 个 消费 者 ， 如 果 为 空 ， 
则 表示 当前 操作 需要 请 求 一 个 数据 。timed 参 数 决 定 是 否 存 在 timeout 时 
| 旧 ，nanos 决 定 了 timeout 的 上 时长。 如果 返回 值 非 空 ， 则 表示 数据 已 经 接 
受 或 者 正常 提供 ， 如 果 为 空 ， 则 表示 失败 (超时 或 者 中 断 ) 。 


SynchronousQueue 内 部 会 维护 一 个 线程 等 竺 队列。 等 竺 队列 中 会 
保存 等 待 线 程 以 及 相关 数据 的 信息 。 比 如 ， 生 产 者 将 数据 放 入 
SynchronousQueue 时 ， 如 果 没 有 消费 者 接收 ， 那 么 数据 本 喘 和 线程 对 


象 都 会 打包 在 队列 中 等 待 〈 因 为 SynchronousQueue 容 积 为 0， 没 有 数据 
可 以 正常 放 入 ) 。 


TransferertransferO 函 数 的 实现 是 SynchronousQueue 的 核心 ， 它 大 
体 上 分 为 三 个 步骤 : 


1. 如 采 等 待 队列 为 空 ， 或 者 队列 中 节点 的 类 型 和 本 次 操作 十 一 至 
的 ， 那 么 将 当前 操作 压 入 队列 等 待 。 比 如 ， 等 待 队 列 中 是 读 线 
程 等 每 ， 本 次 操作 也 钙 读 ， 因 此 这 两 个 读 都 需要 等 行 。 进 入 等 
待 队列 的 线程 可 能 会 被 挂 起 ， 它 们 会 等 待 一 个 “匹配 ?操作 。 

2. 如 果 等 待 队列 中 的 元 素 和 本 次 操作 是 互补 的 〈 比 如 等 待 操作 是 
读 ， 而 本 次 操作 是 写 ) ， 那 么 就 插入 一 个 “完成 "状态 的 节点 ， 
并 且 让 他 “匹配 ”到 一 个 等 每 节点 上 。 接 着 弹出 这 两 个 市 点 ， 并 
且 使 得 对 应 的 两 个 线程 继续 执行 。 

. 如 采 线 程 发 现 等 每 队列 的 节点 束 古 “完成 节操， 那么 帮助 这 个 
节点 完成 任务 。 其 流程 和 步骤 2 是 一 致 的 。 


UJ 


步骤 1 的 实现 如 下 (代码 参考 JDK 7u60) : 


01 SNode h = head; 


02 if (h == null || h.mode == mode) { // WR 
队列 为 空 ， 或 者 模式 相同 

03 if (timed && nanos <= 0) { // 不 进 
行 等 待 

04 if (h != null && h.isCancelled() ) 

05 casHead(h, h.next); Ad 处 理 
取消 行为 


06 else 


07 return null; 


08 } else if (casHead(h, s = snode(s, e, h, mode))) { 

09 SNode m = awaitFulfill(s, timed, nanos); // 等 待 ， 
直到 有 匹配 操作 出 现 

10 if (m == s) { Vf are 
被 取消 

11 clean(s); 

12 return null; 

13 } 

14 if ((h = head) != null && h.next == s) 

15 casHead(h, s.next); // 帮助 S 


的 fulfiller 
16 return (mode == REQUEST) ? m.item : s.item; 


He } 


上 述 代 码 中 ， 第 1 行 SNode 表 示 等 每 队列 中 的 市 点 。 内 部 封 狠 了 当 
前 线程 、next 下 点 、 匹 配 节 点、 数据 内 容 等 信息 。 第 2 行 ， 判 断 当 前 等 
竺 队列 为 空 ， 或 者 队列 中 元 素 的 模式 与 本 次 操作 相同 〈 比 如， 都 是 读 
操作 ， 那 么 都 必须 要 等 待 ) 。 第 8 行 ， 生 成 一 个 新 的 节点 并 置 于 队列 头 
部 ， 这 个 市 点 束 代 表 当 前 线程 。 如 果 入 队 成 功 ， 则 执行 第 9 行 
awaitFulfill0) 芳 数 。 该 函数 会 进行 目 旋 等 每 ， 并 最 终 挂 起 当前 线程 。 直 
到 一 个 与 之 对 应 的 操作 产生 ， 将 其 唤醒 。 线 程 被 唤醒 后 (表示 已 经 读 
取 到 数据 或 者 目 己 产生 的 数据 已 经 被 别 的 线程 读 取 ) ， 在 第 14 一 15 行 
党 试 帮助 对 应 的 线程 完成 两 个 头 部 节点 的 出 队 操作 〈 这 仅仅 是 友情 大 
助 ) 。 并 在 最 后 ， 返 回 读 取 或 者 写 入 的 数据 〈 第 16 行 ) 。 


步骤 2 的 实现 如 下 : 


01 } else if (!isFulfilling(h.mode)) { // 是 否 处 于 fulfill 
状态 

02 if (h.isCancelled()) // 如 果 以 前 取消 
03 casHead(h, h.next); // 弹出 并 重 试 

04 else if (casHead(h, s=snode(s, e, h, FULFILLING|mode) ) ) 
{ 

05 For (G) 4 // 一 直 循 环 和 直到 匹配 
(match) 或 者 没有 等 待 者 了 

06 SNode m = s.next; // m 是 s 的 匹配 者 
(match) 

07 ate CMS anid yet // 已 经 没有 等 待 者 了 
08 casHead(s, null); // FAH fulfill yp 
点 

09 s = null; // 下 一 次 使 用 新 的 节 
点 

10 break; // 重新 开始 主 循环 
11 } 

12 SNode mn = m.next; 

13 if (m.tryMatch(s)) { 

14 casHead(s, mn); // 弹出 s 和 m 

15 return (mode == REQUEST) ? m.item : s.item; 
16 } else // match 失败 

17 s.casNext(m, mn); // 帮助 删除 节点 


20 } 


上 述 代码 中 ， 首 先 判断 头 部 节点 是 否 处 于 fulfil 模 式 。 如 果 是 ， 则 
需要 进入 步骤 3。 和 否则 ， 将 视 自 己 为 对 应 的 fulfil 线 程 。 第 4 行 ， 生 成 一 
个 SNode 元 素 ， 设 置 为 falfil 模 式 并 将 其 压 入 队列 头 部 。 接 着 ， 设 置 m 

(原始 的 队列 头 部 ) 为 s 的 匹配 节点 〈 第 13 行 ) ， 这 个 tryMatch() 操 作 
将 会 激活 一 个 等 竺 线程， 并 将 mm 传递 给 那个 线程 。 如 果 设 置 成 功 ， 则 
表示 数据 投递 完成 ， 将 s 和 m 两 个 节点 弹出 即 可 〈 第 14 行 ) 。 如 果 
tryMatch() 失 败 ， 则 表示 已 经 有 其 他 线程 帮 我 完成 了 操作 ， 那 么 简单 得 
删除 m 节 点 即 可 (第 17 行 ) ， 因 为 这 个 节点 的 数据 已 经 被 投递 ， 不 需 
要 再 次 处 理 ， 然 后 ， 再 次 跳 转 到 第 5 行 的 循环 体 ， 进 行 下 一 个 等 待 线程 
的 匹配 和 数据 投递 ， 直 到 队列 中 没有 等 待 线程 为 止 。 


步骤 3 的 实现 〈 如 果 线 程 在 执行 时 ， 发 现 头 部 元 素 恰好 是 fulfil 模 
式 ， 它 就 会 帮助 这 个 fulfil 节 点 尽快 被 执行 ) : 


} else { // 帮助 一 个 
fulfiller 
SNode m = h.next; // m 是 HAY match 
if (m == null) // 没有 等 待 者 
casHead(h, null); // POM Fulfill ps 
else { 


SNode mn = m.next; 


if (m.tryMatch(h) ) // Z match 
casHead(h, mn); // 弹出 h AL m 
else // match 失 败 


帮助 删除 节点 


SS 


h.casNext(m, mn); / 


上 述 代 码 的 执行 原理 和 步骤 2 是 完全 一 致 的 。 唯 一 的 不 同 是 步 又 3 
不 会 返回 ， 因 为 步 又 3 所 进行 的 工作 是 帮助 其 他 线程 尽快 投递 它们 的 数 
据 ， 而 目 己 并 没有 完成 对 应 的 操作 。 因 此 ， 线 程 进入 步骤 3 后 ， 再 次 进 
入 大 循环 体 (代码 中 没有 给 出 ， 从 步 又 1 开始 重新 判断 条 件 和 投递 数 
据 。 


从 整个 数据 投递 的 过 程 中 可 以 看 到 ， 在 SynchronousQueue 中 ， 参 
与 工作 的 所 有 线程 不 仅仅 是 竞争 资源 的 关系 。 更 重要 的 是 ， 它 们 彼此 
之 间 还 会 互相 帮助 。 在 一 个 线程 内 部 ， 可 能 会 帮助 其 他 线程 完成 它们 
的 工作 。 这 种 模式 可 以 更 大 程度 上 减少 已 饿 的 可 能 ， 提 高 系统 整体 的 
并 行 度 。 


4.5 有关 死 锁 的 问题 


在 学 习 了 无 锁 之 后 ， 让 我 们 重新 回 到 锁 的 世界 吧 ! 在 众多 的 应 用 
程序 中 ， 使 用 锁 的 情况 一 般 要 多 于 无 锁 。 因 为 对 于 应 用 来 说 ， 如 采 业 
务 逻辑 很 复杂 ， 会 极 大 增加 无 锁 的 编程 难度 。 但 如 采 使 用 锁 ， 我 们 就 
不 得 不 对 一 个 新 的 问题 引起 重视 一 一 那 就 是 死 锁 。 


ABT A ee SCRE? 通俗 的 说 ， 和 死 锁 吏 是 两 个 或 者 多 个 线程 ， 相 互 
占用 对 方 需要 的 资源 ， 而 都 不 进行 释放 ， 导 致 彼此 之 间 都 相互 等 得 对 
方 释放 资源 ， 产 生 了 无 限制 等 待 的 现象 。 死 锁 一 旦 发 生 ， 如 果 没 有 外 
力 介 入 ， 这 种 等 待 将 永远 存在 ， 从 而 对 程序 产生 疗 重 的 影响 。 


用 来 摘 述 死 氏 问 题 的 一 个 有 名 的 场景 是 “哲学 家 束 餐 ”问题 。 哲 学 
家 就 餐 问 题 可 以 这 样 表述 ， 假 设 有 五 位 哲学 家 围 坐 在 一 张 圆 形 和 餐 果 
旁 ， 做 以 下 两 件 事情 之 一 : 吃饭， 或 者 思考 。 吃 东西 的 时 候 ， 他 们 整 
停止 思考 ， 思 考 的 时 候 也 停止 号 东西 。 和 餐 梨 中 间 有 一 大 碗 意大利 面 ， 
每 两 个 哲学 家 之 间 有 一 只 餐 勾 。 因 为 用 一 只 餐 叉 很 难 吃 到 意大利 面 ， 
所 以 假设 哲学 家 必须 用 两 只 餐 叉 吃 东西 。 他 们 只 能 使 用 目 己 左右 手边 
的 那 两 只 餐 又 。 哲 学 家 了 吏 餐 问题 有 时 也 用 米饭 和 簧 子 而 不 是 意大利 面 
和 和 餐 叉 来 描述 ， 因 为 很 明显 ， 吃 米饭 必须 用 两 根 和 馈 子 。 


哲学 家 从 来 不 交谈 ， 这 吏 很 危险 ， 可 能 产生 死 锁 ， 每 个 哲学 家 都 
拿 着 左手 的 餐 又 ， 永 远 都 在 等 右边 的 餐 又 〈 或 者 相反 ) 。 如 图 4.3 所 
示 ， 显 示 了 这 种 情况 。 


图 4-3 ”哲学 家 就 餐 问 题 


最 简单 的 情况 就 是 只 有 两 个 哲学 家 ， 假 设 是 A 和 B。 桌 面 也 只 有 两 
个 又 子 。A 左 手 拿 着 其 中 一 只 又 子 ，B 也 -一样 。 这 样 他 们 的 右手 等 在 等 
待 对 方 的 叉子 ， 并 且 这 种 等 待 会 一 直 持续 ， 从 而 导致 程序 永远 无 法 正 
常 执行 。 


下 面 让 我 们 用 一 个 简单 的 例子 来 模拟 这 个 过 程 : 


01 public class DeadLock extends Thread { 


02 protected Object tool; 

03 static Object forki = new Object(); 
04 static Object fork2 = new Object(); 
05 

06 public DeadLock(Object obj) { 

07 this.tool = obj; 

08 if (tool == fork1) { 

09 this,setName(" 哲 学 家 A" ) ， 


10 } 


if (tool == fork2) { 


this.setName(" 哲 学 家 B" ) ， 


@Override 
public void run() { 
if (tool == fork1) { 
synchronized (fork1i) { 
try { 
Thread.sleep(500) ; 
} catch (Exception e) { 
e.printStackTrace(); 


i 
synchronized (fork2) { 


` 


System.out.printlLn(" 大 学 家 Aj 


} 
if (tool == fork2) { 
synchronized (fork2) { 
try { 
Thread.sleep(500); 
} catch (Exception e) { 


e.printStackTrace(); 


PAIT Y); 


38 synchronized (fork1i) { 
39 System.out.println(" 大 学 家 B 开 始 吃饭 了 " ) ; 


46 public static void main(String[] args) throws 


InterruptedException { 


47 DeadLock 哲学 家 A = new DeadLock(fork1); 
48 DeadLock 哲学 家 B = new DeadLock(fork2); 
49 FARA. start(); 

50 ARB. start(); 

51 Thread.sleep(1000); 

52 } 

53 } 


上 述 代 码 模 拟 了 两 个 冰 学 家 互相 等 待 对 方 的 久子 。 哲 学 家 A 先 占 
用 又 子 1， 哲 学 家 B 占 用 又 子 2， 接 着 他 们 天 相互 等 待 ， 都 没有 办 法 同 
yy ok tr BAS AAA -° 


如 果 在 实际 环境 中 ， 遇 到 了 这 种 情况 ， 通 常 的 表现 就 是 相关 的 进 
人 
过 这 种 表面 现象 只 能 用 来 猜测 问题 。 如 果 想 要 确认 问题 ， 还 需要 使 用 
JDK 提 供 的 一 套 专业 工具 


首先 ， 我 们 可 以 使 用 jps 命 令 得 到 java 进 程 的 进程 ID ， 接 着 使 用 
jstack 命 令 得 到 线程 的 线程 堆栈 : 


C:\Users\Administrator>jps 

8404 

944 

3992 DeadLock 

3260 Jps 

// 使 用 jstack 查 看 进程 内 所 有 的 线程 堆栈 

C:\Users\Administrator>jstack 3992 

// 省 略 部 分 输出 ， 只 列 出 当前 与 死 锁 有 关 的 线程 

"哲学 家 B" #9 prio=5 os_prio=0 tid=0x01ccf400 nid=0xb70 waiting 


for monitor entry [0x1597f000 | 
java.lang.Thread.State: BLOCKED (on object monitor ) 
at 
geym.conc.ch4.deadlock.DeadLock.run(DeadLock. java: 42) 
- waiting to lock <0x046b3430> (a java.lang.Object) 
- locked <0x046b3438> (a java.lang.Object) 


"gre RA" #8 prio=5 os_prio=0 tid=0x01ccec00 nid=0x1064 waiting 
for monitor entry [0x160ff000] 
java.lang.Thread.State: BLOCKED (on object monitor) 
at 
geym.conc.ch4.deadlock.DeadLock.run(DeadLock. java: 29) 
- waiting to lock <0x046b3438> (a java.lang.Object) 
- locked <0x046b3430> (a java.lang.Object) 


/7/ 目 动 找到 了 一 个 死 锁 ， 确 认 死 锁 的 存在 


Sx 


Found one Java-level deadlock: 


"HERE" : 
waiting to lock monitor Ox1i5b5bd6c (object 0x046b3430, a 
java.lang.Object), 
which is held by "哲学 家 A" 
"HZA": 
waiting to lock monitor ©x01c1705c (object 0x046b3438, a 
java.lang.Object), 


which is held by "?24?22B" 


Java stack information for the threads listed above: 


"ERB" 
at 
geym.conc.ch4.deadlock.DeadLock.run(DeadLock. java: 42) 
- waiting to lock <0x046b3430> (a java.lang.Object) 
- locked <0x046b3438> (a java.lang.Object) 
"HERA" : 
at 


geym.conc.ch4.deadlock.DeadLock.run(DeadLock. java: 29) 
- waiting to lock <0x046b3438> (a java.lang.Object) 
- locked <0x046b3430> (a java.lang.Object) 


Found 1 deadlock. 


上 面 显 示 了 jstack 的 部 分 输出 。 可 以 看 到 ， 哲 学 家 A 和 哲学 家 B 两 
个 线程 发 生 了 死 锁 。 并 且 在 最 后 ， 可 以 看 到 两 者 相互 等 竺 的 锁 的 ID。 
同时 ， 死 锁 的 两 个 线程 均 处 于 BLOCK 状态 。 


ROAR REE eC BL, BRT EC Eb, Fh ED BS 
征 使 用 第 三 章节 介绍 的 重 入 锁 ， 通 过 重 入 锁 的 中 断 或 者 限时 等 待 可 以 
有 效 规避 死 锁 带 来 的 问题 。 大 家 可 以 再 回顾 一 下 相关 内 容 。 
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第 5 章 ” 并行 模式 与 算法 


由 于 并 行程 序 设 计 比 第 行 程序 复杂 得 多 。 因 此 ， 我 强烈 建议 大 家 
可 以 熟悉 和 了 解 一 些 和 常见 的 设计 方法 。 束 好 像 练习 武术 一 样 ， 一 招 一 
式 都 是 要 经 过 学 习 的 。 如 果 目 己 胡 乱 打 一 气 ， 效 果 不 见 得 好 。 前 人 会 
总 结 一 些 武 术 套 路 ， 对 于 初学 者 来 说 ， 不 需要 发 挥 目 己 的 想象 力 ， 只 
要 按照 武术 套路 出 拳 整 可 以 了 。 等 到 练 到 了 一 定 的 高 度 ， 就 可 以 以 无 
招 胜 有 招 了 ， 而 不 必 拘 泥 于 套路 。 这 些 武 术 套路 和 招数 ， 对 应 到 软件 
开发 中 来 ， 吏 设 计 模 式 。 在 这 一 章 中 ， 我 将 重点 癌 大 家 介绍 一 些 有 
关 并 行 的 设计 模式 以 及 算法 。 这 些 都 是 前 人 的 经 验 总 结 和 智慧 的 结 
唱 。 大 家 可 以 在 熟知 其 思想 和 原理 的 基础 之 上 ， 再 根据 目 己 的 需求 进 
行 扩展 ， 可 能 会 达到 更 好 的 效果 。 


5.1 探讨 单 例 模式 


单 例 模式 是 设计 模式 中 使 用 最 为 普 电 的 模式 之 一 。 它 是 一 种 对 和 象 
创建 模式 ， 用 于 产生 一 个 对 象 的 具体 实例 ， 它 可 以 确保 系统 中 一 个 类 
只 产生 一 个 实例 。 在 Java 中 ， 这 样 的 行为 能 市 来 两 大 好 处 : 


。 对 于 频繁 使 用 的 对 象 ， 可 以 省 略 new 操 作 花 费 的 时 间 ， 这 对 于 
那些 重量 级 对 象 而 言 ， 是 非常 可 观 的 一 笔 系 统 开 销 ; 

。 由 于 new 操 作 的 次 数 减少 ， 因 而 对 系统 内 存 的 使 用 频率 也 会 降 
低 ， 这 将 减轻 GC 压 力 ， 缩 短 GC 停 顿时 间 。 


严格 来 说 ， 单 例 模 式 与 并 行 没 有 直接 的 关系 。 这 里 我 希望 讨论 这 
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线程 环境 中 使 用 它们 。 并 且 ， 系 统 中 使 用 单 例 的 地 方 可 能 非常 频繁 ， 
因此 ， 我 们 非常 迫切 需要 一 种 高 效 的 单 例 实 现 。 


下 面 给 出 了 一 个 单 例 的 实现 ， 这 个 实现 是 非常 稍 单 的 ， 但 无 疑 是 
一 个 正确 并 且 民 好 的 实现 。 
public class Singleton { 


private Singleton(){ 


System.out.printin("Singleton is create"); 


private static Singleton instance = new Singleton(); 


1 
2 
3 
4 
5 
6 public static Singleton getInstance() { 
7 


return instance; 


使 用 以 上 方式 创建 单 例 有 几 点 必须 特别 注意 。 因 为 我 们 要 保证 系 
统 中 不 会 有 人 意外 创建 多 余 的 实例 ， 因 此 ， 我 们 把 Singleton 的 构造 函 
数 设置 为 private。 这 点 非常 重要 ， 这 了 吏 警 告 所 有 的 开发 人 员 ， 不 能 随 
便 创建 这 个 类 的 实例 ， 从 而 有 效 避 免 该 类 被 错误 的 创建 。 


第 二 点 ，instance 对 象 必 须 是 private 并 且 static 的 。 如 果 不 是 
private， 那 么 instance 的 安全 性 无 法 得 到 保证 。 一 个 小 小 的 意外 就 可 能 
使 得 instance 变 成 null。 其 次 ， 因 为 工厂 方法 getInstance() 必 须 是 static 
的 ， 因 此 对 应 的 instance 也 必须 是 static ° 


这 个 单 例 的 性 能 是 非常 好 的 ， 因 为 getInstance() 方 法 只 是 简单 地 返 
回 instance， 并 没有 任何 锁 操作 ， 因 此 它 在 并 行程 序 中 ， 会 有 展 好 的 表 
现 。 


但 是 这 种 方式 有 一 点 明显 不 足 ， 束 是 Singleton 构 造 玉 数 ， 或 者 说 
Singleton 实 例 在 什么 时 候 创 建 是 不 受 控制 的 。 对 于 静态 成 员 instance， 
它 会 在 类 第 一 次 初始 化 的 时 候 被 创建 。 这 个 时 刻 并 不 一 定 是 
getInstance() 方 法 第 一 次 被 调用 的 时 候 。 


比如 ， 如 采 你 的 单 例 像 是 这 样 的 : 


public class Singleton { 
public static int STATUS=1; 
private Singleton(){ 


System.out.println("Singleton is create"); 


private static Singleton instance = new Singleton(); 
public static Singleton getInstance() { 


return instance; 


注意 ， 这 个 单 例 还 包含 一 个 表示 状态 的 静态 成 员 STATUS。 此 

上 时， 在 相同 任何 地 方 引 用 这 个 STATUS 都 会 导致 instance 实 例 被 创建 

(任何 对 Singleton 方 法 或 者 字段 的 引用 ， 都 会 导致 类 初始 化 ， 并 创建 

instance 实 例 ， 但 是 类 初始 化 只 有 一 次 ， 因 此 instance 实 例 永 远 只 会 被 
创建 一 次 ) 。 比 如 : 


System.out.printin(Singleton.STATUS) ; 
上 述 printn 会 打印 出 : 


Singleton is create 


1 


可 以 看 到 ， 即 使 系统 没有 要 求 创 建 单 例 ，new Singleton() 也 会 被 调 
H o 


如 果 大 家 觉得 这 个 小 小 的 不 足 并 不 重要 ， 我 认为 这 种 单 例 模式 是 
一 种 不 错 的 选择 。 它 容易 实现 ， 代 码 易 读 而 且 性 能 优越 。 


但 如 有 果 你 想 精 确 控 制 instance 的 创建 时 间 ， 那 么 这 种 方式 整 不 太 友 
善 了 。 我 们 需要 寻找 一 种 新 的 方法 ， 一 种 支持 延迟 加 载 的 策略 ， 它 只 
会 在 instance 被 第 一 次 使 用 时 ， 创 建 对 象 。 具 体 实现 如 下 : 


01 public class LazySingleton { 


02 private LazySingleton() { 

03 System.out.println("LazySingleton is create"); 

04 } 

05 private static LazySingleton instance = null; 

06 public static synchronized LazySingleton getInstance() { 
07 if (instance == null) 

08 instance = new LazySingleton(); 

09 return instance; 

10 } 

11 } 


这 个 LazySingleton 的 核心 思想 如 下 : 最 初 ， 我 们 并 不 需要 实例 化 
instance， 而 当 getInstance() 方 法 被 第 一 次 调用 时 ， 创 建 单 例 对 象 。 为 了 
防止 对 象 被 多 次 创建 ， 我 们 不 得 不 使 用 synchronized 进 行 方法 同步 。 这 
种 实现 的 好 处 是 ， 充 分 利用 了 延迟 加 载 ， 只 在 真正 需要 时 创建 对 象 。 
但 坏处 也 很 明显 ， 并 发 环境 下 加 锁 ， 竞 争 激 烈 的 场合 对 性 能 可 能 产生 
一 定 的 影响 。 但 总 体 上 ， 这 是 一 个 非常 易于 实现 和 理解 的 方法 。 


此 外 ， 还 有 一 种 被 称 为 双重 检查 模式 的 方法 可 以 用 于 创建 单 例 。 
但 我 并 不 打算 在 这 里 介绍 它 ， 因 为 这 是 一 种 非常 丑陋 、 复 洒 的 方法 ， 
甚至 在 低 版 本 的 JDK 中 都 不 能 保证 正确 性 。 因 此 ， 绝 不 推荐 大 家 使 
用 。 如 采 大 家 阅读 到 相关 文档 ， 我 也 强烈 建议 大 家 不 要 在 这 种 方法 上 
化 费 太 多 时 间 。 


在 上 述 介绍 的 两 种 单 例 实现 中 ， 可 以 说 是 各 有 千秋 。 有 没有 一 种 
方法 可 以 结合 二 者 之 优势 呢 ? 答案 是 肯定 的 : 


01 public class StaticSingleton { 


02 private StaticSingleton(){ 

03 System.out.println("StaticSingleton is create"); 

04 } 

05 private static class SingletonHolder { 

06 private static StaticSingleton instance = new 


StaticSingleton(); 


07 } 

08 public static StaticSingleton getInstance() { 
09 return SingletonHolder.instance; 

10 } 

na y 
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先 getInstance() 方 法 中 没有 锁 ， 这 使 得 在 高 并 发 环境 下 性 能 优越 。 其 
次 ， 只 有 在 getImnstance() 方 法 被 第 一 次 调用 时 ，StaticSingleton 的 实例 才 
会 被 创建 。 因 为 这 种 方法 巧妙 地 使 用 了 内 部 类 和 类 的 初始 化 方式 。 内 
部 类 SingletonHolder 被 申明 为 private， 这 使 得 我 们 不 可 能 在 外 部 访问 并 
初始 化 它 。 而 我 们 只 可 能 在 getInstance0 内 部 对 SingletonHolder 类 进行 
初始 化 ， 利 用 虚拟 机 的 类 初始 化 机 制 创建 单 例 。 


5.2 不 变 模 式 


在 并 行 软件 开发 过 程 中 ， 同 步 操 作 似乎 是 必 不 可 少 的 。 当 多 线程 
对 同一 个 对 象 进行 读 写 操 作 时 ， 为 了 保证 对 象 数 据 的 一 致 性 和 正确 
性 ， 有 必要 对 对 象 进行 同步 。 而 同步 操作 对 系统 性 能 是 有 相当 的 损 
耗 。 为 了 能 尽 可 能 地 去 除 这 些 同步 操作 ， 提 高 并 行程 序 性 能 ， 可 以 使 
用 一 种 不 可 改变 的 对 象 ， 依 靠 对 象 的 不 变性 ， 可 以 确保 其 在 没有 同步 
操作 的 多 线程 环境 中 依然 始终 保持 内 部 状态 的 一 致 性 和 正确 性 。 这 束 
征 不 变 模 式 。 


不 变 模 式 天 生 束 是 多 线程 友好 的 ， 它 的 核心 思想 是 ， 一 个 对 象 一 
旦 被 创建 ， 则 它 的 内 部 状态 将 永远 不 会 发 生 改变 。 所 以 ， 没 有 一 个 线 
程 可 以 修改 其 内 部 状态 和 数据 ， 同 时 其 内 部 状态 也 绝 不 会 目 行 发 生 改 
变 。 基 于 这 些 特 性 ， 对 不 变 对 象 的 多 线程 操作 不 需要 进行 同步 控制 。 


同时 还 需要 注意 ， 不 变 模 式 和 只 读 属 性 是 有 一 定 的 区 别 的 。 不 变 
模式 是 比 只 读 属性 具有 更 强 的 一 致 性 和 不 变性 。 对 只 读 属性 的 对 象 而 
言 ， 对 和 象 本 身 不 能 被 其 他 线程 修改 ， 但 是 对 象 的 目 喘 状态 却 可 能 目 行 
修改 。 


比如 ， 一 个 对 象 的 存活 时 间 (对 象 创建 时 间 和 当前 时 间 的 时 间 
Ze) 是 只 读 的 ， 因 为 任何 一 个 第 三 方 线程 都 不 能 修改 这 个 属性 ， 但 是 
这 是 一 个 可 变 的 属性 ， 因 为 随 厦 时 间 的 推移 ， 存 活 时 间 时 刻 都 在 发 生 
变化 。 而 不 变 模 式 则 要 求 ， 无 论 出 于 什么 原因 ， 对 象 目 创建 后 ， 其 内 
部 状态 和 数据 保持 绝对 的 稳定 。 


因此 ， 不 变 模 式 的 主要 使 用 场景 需要 满足 以 下 2 个 条 件 : 


。 当 对 象 创建 后 ， 其 内 部 状态 和 数据 不 再 发 生 任 何 变 化 。 
。 RERE, WA RIEV] 。 


在 Java 语 言 中 ， 不 变 模 式 的 实现 很 简单 。 为 确保 对 象 被 创建 后 ， 
不 发 生 任何 改变 ， 并 保证 不 变 模 式 正 闻 工 作 ， 只 需要 注意 以 下 4 点 : 


。 去 除 setter 方 法 以 及 所 有 修改 自身 属性 的 方法 。 

。 将 所 有 属性 设置 为 私有 ， 并 用 final 标 记 ， 确 你 其 不 可 修改 。 
。 确保 没有 子 类 可 以 重 载 修改 它 的 行为 。 

© 有 一 个 可 以 创建 完整 对 象 的 构造 函数 。 


以 下 代码 实现 了 一 个 不 变 的 产品 对 象 ， 它 拥有 序列 号 、 名 称 和 价 
格 二 个 属性 。 


public final class Product { // 确 保 无 
FR 

private final String no; // 私 有 属 
性 ， 不 会 被 其 他 对 象 获取 

private final String name; //final 


保证 属性 不 会 被 2 次 赋值 


private final double price; 


public Product(String no, String name, double price) { 
// 在 创建 对 象 时 ， 必 须 指定 数据 
super(); // 因 为 创 
建 之 后 ， 无 法 进行 修改 


this.no = no; 
this.name = name; 


this.price = price; 


public String getNo() { 
return no; 

t 

public String getName() { 
return name; 

t 

public double getPrice() { 


return price; 


在 不 变 模式 的 实现 中 ，final 天 键 字 起 到 了 重要 的 作用 。 对 属性 的 
final 定 义 确 保 所 有 数据 只 能 在 对 象 被 构造 时 赋值 1 次 。 之 后 ， 歌 永远 不 
再 发 生 改变 。 而 对 class 的 final 确 保 了 类 不 会 有 子 类 。 根 据 里 氏 代 换 原 
则 ， 子 类 可 以 完全 的 奉 代 父 类 。 如 果 父 类 是 不 变 的 ， 那 么 子 类 也 必须 
是 不 变 的 ， 但 实际 上 我 们 并 无 法 约束 这 点 ， 为 了 防止 子 类 做 出 一 些 意 
外 的 行为 ， 这 里 就 干脆 把 子 类 都 禁用 了 。 


在 JDK 中 ， 不 变 模式 的 应 用 非常 广泛 。 其 中 ， 最 为 典型 的 吏 是 
java.lang.String 类 。 此 外 ， 所 有 的 元 数据 类 包 闭 类， 都 是 使 用 不 变 模式 
实现 的 。 主 要 的 不 变 模 式 类 型 如 下 : 


e java.lang.String 


java.lang.Boolean 


java.lang.Byte 


java.lang.Character 


java.lang.Double 


java.lang.Float 


java.lang. Integer 


java.lang. Long 


java.lang.Short 


由 于 基本 数据 类 型 和 String 类 型 在 实际 的 软件 开发 中 应 用 极其 广 
泛 ， 使 用 不 变 模 式 后 ， 所 有 实例 的 方法 均 不 需要 进行 同步 操作 ， 保 证 
了 它们 在 多 线程 环境 下 的 性 能 。 


注意 : 不 变 模式 通过 回避 问题 而 不 是 解决 问题 的 态度 来 处 理 多 线 
程 并 发 访问 控制 。 不 变 对 象 是 不 需要 进行 同步 操作 的 。 由 于 并 发 
同步 会 对 性 能 产生 不 恨 的 影响 ， 因 此 ， 在 需求 允许 的 情况 下 ， 不 
变 模式 可 以 提高 系统 的 并 发 性 能 和 并 发 量 。 


5.3 ”生产 考 - 消 费 者 模式 


生产 者 -消费 者 模式 是 一 个 经 典 的 多 线程 设计 模式 ， 它 为 多 线程 间 
的 协作 提供 了 民 好 的 解决 方案 。 在 生产 者 -消费 者 模式 中 ， 通 第 有 了 两 类 
线程 ， 即 者 干 个 生产 者 线程 和 寿 干 个 消费 者 线程 。 生 产 痢 线程 负责 拓 
交 用 户 请 求 ， 消 费 者 线程 则 负责 具体 处 理 生 产 者 提交 的 任务 。 生 产 者 
和 消费 者 之 间 则 通过 共 至 内 存 组 促 区 进行 通信 。 


如 图 5.1 所 示 ， 展 示 了 生产 者 -消费 者 模式 的 基本 结构 。 三 个 生产 
者 线程 将 任务 提交 到 共 译 内 存 缓冲 区 ， 消 费 者 线程 并 不 直接 与 生产 者 
线程 通信 ， 而 在 共 至 内 存 绥 促 区 中 获取 任务 ， 并 进行 处 理 。 
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图 5.1 生产 者 -消费 者 模式 架构 图 
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注意 : 生产 者 -消费 者 模式 中 的 内 存 缓存 区 的 主要 功能 是 数据 在 多 
线程 间 的 共享 ， 此 外 ， 通 过 该 缓冲 区 ， 可 以 缓解 生产 者 和 消费 者 
间 的 性 能 差 


生产 者 -消费 者 模式 的 核心 组 件 是 共 至 内 存 缓存 区 ， 它 作为 生产 者 
和 消费 者 间 的 通信 桥梁 ， 避 人 免 了 生产 者 和 消费 者 的 直接 通信 ， 从 而 将 


生产 者 和 消费 者 进行 解 厢 。 生 产 者 不 需要 知道 消费 者 的 存在 ， 消 费 考 
也 不 需要 知道 生产 者 的 存在 。 


同时 ， 由 于 内 存 缓冲 区 的 存在 ， 人 允许 生产 者 和 消费 者 在 执行 速度 
上 存在 时 间 差 ， 无 论 是 生产 者 在 某 一 局 部 时 间 内 速度 高 于 消费 者 ， 还 
苹 消 费 者 在 局 部 时 间 内 高 于 生产 者 ， 都 可 以 通过 共 至 内 存 绥 冲 区 得 到 
缓解 ， 确 保 系 统 正常 运行 。 


生产 者 -消费 者 模式 的 主要 角色 如 表 5.1 所 示 。 


表 5.1 生产 者 -消费 者 模式 主要 角色 


角色 作用 

生产 者 村 提交 用 户 请 求 ， 提 取 用 户 任务 ， 并 装 入 内 存 缓冲 区 
消费 者 在 内 存 缓冲 区 中 提取 并 处 理 任 务 

内 存 缓冲 区 缓存 生产 者 提交 的 任务 或 数据 ， 供 消费 者 使 用 

任务 生成 者 向 内 在 缓冲 区 提交 的 数据 结构 

Main 使 用 生产 者 和 消费 者 的 客户 端 


图 5.2 显 示 了 生产 者 -消费 者 模式 一 种 实现 的 具体 结构 。 
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图 5.2 ”生产 者 -消费 者 实现 类 图 


其 中 ，BlockigQueue 充 当 了 共享 内 存 缓冲 区 ， 用 于 维护 任务 或 数 
据 队列 (PCData 对 象 ) 。 我 强烈 建议 大 家 先 回 顾 一 下 第 3 章 有 关 
BlockingQueue 的 相关 知识 ， 对 于 理解 整个 生产 者 和 消费 者 结构 有 重要 
的 帮助 。PCData 对 象 表示 一 个 生产 任务 ， 或 者 相关 任务 的 数据 。 生 产 
者 对 象 和 消费 者 对 象 均 引用 同一 个 BlockigQueue 实 例 。 生 产 者 负责 创 
建 PCData 对象， 并 将 它 加 入 BlockigQueue 中 ， 消 费 者 则 从 
BlockigQueue 队 列 中 获取 PCData。 


基于 图 5.2 所 示 结 构 ， 实 现 一 个 基于 生产 者 -消费 者 模式 的 求 整数 
平方 的 并 行程 序 。 


首先 ， 生 产 者 线程 的 实现 如 下 ， 它 构建 PCData 对 象 ， 并 放 入 
BlockingQueue 队 列 中 。 


public class Producer implements Runnable { 
private volatile boolean isRunning = true; 
private BlockingQueue < PCData> queue; 
// 内 存 缓冲 区 
private static AtomicInteger count = new AtomicInteger(); 
// 总 数 ， 原 了 于 操作 
private static final int SLEEPTIME = 1000; 


public Producer(BlockingQueue<PCData> queue) { 


this.queue = queue; 


public void run() { 
PCData data = null; 


Random r = new Random(); 


System.out.printlin("start producer 
id="+Thread.currentThread().getId()); 
try { 
while (isRunning) { 
Thread.sleep(r.nextInt(SLEEPTIME) ); 


data = new PCData(count.incrementAndGet()); 
// 构 造 任务 数据 


System.out.println(data+" is put into queue"); 


if (!queue.offer(data, 2, TimeUnit.SECONDS)) { 


// 提 交 数 据 到 缓冲 区 中 


System.err.printin("failed to put data: " + 


data); 
} 
} 

} catch (InterruptedException e) { 
e.printStackTrace(); 
Thread.currentThread().interrupt(); 

} 

} 


public void stop() { 


isRunning = false; 


对 应 的 消费 者 的 实现 如 下 。 它 从 BlockingQueue 队 列 中 取出 PCData 
对 象 ， 并 进行 相应 的 计算 。 


public class Consumer implements Runnable { 
private BlockingQueue<PCData> queue; 
// 绥 冲 区 
private static final int SLEEPTIME = 1000; 


public Consumer (BlockingQueue<PCData> queue) { 


this.queue = queue; 


public void run() { 
System.out.printin("start Consumer id=" 


+ Thread.currentThread().getId()); 


Random r = new Random(); // 随 机 
等 竺 时间 
try { 
while(true) { 
PCData data = queue.take(); // 提 取 
任务 
if (null != data) { 
int re = data.getData() * data.getData(); 
// 计 算 平方 


System.out.println(MessageFormat.format(" 


{O}*{1}={2}", 


data.getData(), data.getData(), 


re)); 
Thread.sleep(r.nextInt(SLEEPTIME) ); 
} 
} 

} catch (InterruptedException e) { 
e.printStackTrace(); 
Thread.currentThread().interrupt(); 

} 

} 
} 


PCData 作 为 生产 者 和 消费 者 之 间 的 共 吾 数据 模型 ， 定 义 如 下 : 


public final class PCData { // 任 务 
相关 的 数据 

private final int intData; / 13K 
据 


public PCData(int d){ 
intData=d; 

} 

public PCData(String d){ 
intData=Integer.valueOf(d); 

} 

public int getData(){ 


return intData; 


@Override 
public String toString(){ 


return "data:"+intData; 


在 主 函 数 中 ， 创 建 三 个 生产 者 和 三 个 消费 者 ， 并 让 它们 协作 运 
行 。 在 主 函 数 的 实现 中 ， 定 义 LinkedBlockingQueue 作 为 BlockingQueue 
的 实现 类 。 


public class Main { 
public static void main(String[] args) throws 
InterruptedException { 
// 建 立 缓冲 区 
BlockingQueue<PCData> queue = new LinkedBlockingQueue 
<PCData> (10); 


Producer producer1 = new Producer(queue); 


// 建 立 生 产 者 
Producer producer2 = new Producer (queue); 
Producer producer3 = new Producer (queue); 


Consumer consumer1 = new  Consumer(queue); 


/ NTI BF 


Consumer consumer2 = new Consumer (queue); 
Consumer consumer3 = new Consumer (queue); 
ExecutorService service = 
Executors.newCachedThreadPool(); // 建 立 线 程 池 


service.execute(producer 1); 


MEITE A 
service.execute(producer2); 
service.execute(producer3); 


service.execute(consumer1); 
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service.execute(consumer2); 
service.execute(consumer3); 
Thread.sleep(10 * 1000); 


producer1.stop(); 


// 停 止 生 产 者 
producer2.stop(); 
producer3.stop(); 
Thread. sleep(3000); 


service.shutdown(); 


注意 : 生产 者 -消费 者 模式 很 好 地 对 生产 者 线程 和 消费 者 线程 进行 
解 厢 ， 优 化 了 系统 整体 结构 。 同 时 ， 由 于 缓冲 区 的 作用 ， 人 允许 生 
产 者 线程 和 消费 者 线程 存在 执行 上 的 性 能 差异 ， 从 一 定 程度 上 组 
解 了 性 能 瓶颈 对 系统 性 能 的 影响 。 


5.4 ”高 性 能 的 生产 者 -消费 者 : 无 
锁 的 实现 


BlockigQueue 用 于 实现 生产 者 和 消费 者 一 个 不 错 的 选择 。 它 可 以 
很 卓然 地 实现 作为 生产 者 和 消费 者 的 内 存 绥 冲 区 。 但 是 BlockigQueue 
并 不 是 一 个 高 性 能 的 实现 ， 它 完全 使 用 锁 和 阻塞 等 符 来 实现 线程 间 的 
同步 。 在 高 并 发 场合 ， 它 的 性 能 并 不 是 特别 的 优越 。 惑 像 之 前 我 已 经 
提 过 的 : ConcurrentLinkedQueue 是 一 个 高 性 能 的 队列 ， 但 是 
BlockingQueue 只 是 为 了 方便 数据 共享 。 


而 ConcurrentLinkedQueue 的 秘 记 就 在 于 大 量 使 用 了 无 锁 的 CAS 操 
作 。 同 理 ， 如 果 我 们 使 用 CAS 来 实现 生产 者 -消费 者 模式 ， 也 同样 可 以 
获得 可 观 的 性 能 提升 。 不 过 正如 大 家 所 见 ， 使 用 CAS 进 行 编程 是 非常 
办 难 的 ， 但 有 一 个 好 消息 是 ， 目 前 有 一 个 现成 的 Disruptor 框 架 ， 它 已 
经 帮助 我 们 实现 了 这 一 个 功能 。 


5.4.1 无 锁 的 缓存 框架 : Disruptor 


Disruptor 框 架 古 由 LMAX 公 司 开 发 的 一 球 融 效 的 无 锁 内 存 队列 。 
它 使 用 无 锁 的 方式 实现 了 一 个 环形 队列 ， 非 常 适合 于 实现 生产 者 和 消 
费 者 模式 ， 比 如 事件 和 消 恩 的 发 布 。 在 Disruptor 中 ， 别 出 心 裁 地 使 用 
了 环形 队列 (RingBuffer) 来 代替 普通 线性 队列 ， 这 个 环形 队列 内 部 
实现 为 一 个 普通 的 数组 。 对 于 一 般 的 队列 ， 势 必要 提供 队列 同步 head 
和 尾部 tail 两 个 指针 ， 用 于 出 队 和 入 队 ， 这 样 无 疑惑 增加 了 线程 协作 的 


复杂 度 。 但 如 果 队 列 是 环形 的 ， 则 只 需要 对 外 提供 一 个 当前 位 置 
cursor， 利 用 这 个 指针 既 可 以 进入 入 队 也 可 以 进行 出 队 操 作 。 由 于 环形 
队列 的 缘故 ， 队 列 的 总 大 小 必须 事 移 指定 ， 不 能 动态 扩展 。 为 了 能 够 
快速 从 一 个 序列 (sequence) 对 应 到 数组 的 实际 位 置 《每 次 有 元 素 入 
I, ÆJI) ，Disruptor 要 求 我 们 必须 将 数组 的 大 小 设置 为 2 的 整 
数 次 方 。 这 样 通过 sequence &(queueSize-1) 就 能 立即 定位 到 实际 的 元 素 
位 置 index。 这 个 要 比 取 余 (%) 操作 快 得 多 。 


如 果 大 家 不 理解 上 和 面 的 sequence &(queueSize-1)， 我 在 这 里 再 简单 
说 明 一 下 。 如 采 queueSize 是 2 的 整数 次 需 ， 则 这 个 数字 的 二 进 制 表示 
必然 是 10、100、1000、10000 等 形式 。 因 此 ，queueSize-1 的 二 进 制 则 
是 一 个 全 1 的 数字 。 因 此 它 可 以 将 seqdquence 限 定 在 queueSize-1 苑 围 内 ， 
并 且 不 会 有 任何 一 位 是 浪费 的 。 


如 图 5.3 所 示 ， 显 示 了 RingBuffer 的 结构 。 生 产 者 癌 缓 冲 区 中 写 入 
数据 ， 而 消费 者 从 中 读 取 数据 。 生 产 者 写 入 数据 时 ， 使 用 CAS 控 作 ， 
消费 者 读 取 数据 时 ， 为 了 防止 多 个 消费 者 处 理 同一 个 数据 ， 也 使 用 
CAS 操 作 进行 数据 保护 。 
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图 5.3 ”Disruptor 的 RingBuffer 结 构 


这 种 固定 大 小 的 环形 队列 的 男 外 一 个 好 处 就 古 可 以 做 到 完全 的 内 
存 复 用 。 在 系统 的 运行 过 程 中 ， 不 会 有 新 的 空间 需要 分 配 或 者 老 的 空 
间 和 需要 回收 。 因 此 ， 可 以 大 大 减少 系统 分 配 空间 以 及 回收 空间 的 额外 
开销 。 


5.4.2 ”用 Disruptor 实 现 生产 者 -消费 者 
案例 


现在 我 们 已 经 基本 了 解 了 Disruptor 的 基本 实现 。 在 本 节 ， 我 们 将 
展示 一 下 Disruptor 的 基本 使 用 和 API， 这 里 ， 我 们 使 用 的 版 本 是 
disruptor-3.3.2， 不 同 版 本 的 disruptor 可 能 会 有 细微 的 差别 ， 也 请 大 家 留 
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这 里 ， 我 们 的 生产 者 不 断 产生 整数 ， 消 费 者 读 取 生产 者 的 数据 
并 计算 其 平方 。 


目 先 ， 我 们 还 是 需要 一 个 代表 数据 的 PCData: 


public class PCData 
{ 
private long value; 
public void set(long value) 
{ 
this.value = value; 
} 
public long get(){ 


return value; 


消费 者 实现 为 WorkHandler 接 口 ， 它 来 目 Disruptor 框 架 : 


public class Consumer implements WorkHandler<PCData> { 
@Override 
public void onEvent(PCData event) throws Exception { 


System.out.printin(Thread.currentThread().getId() + 


+ event.get() * event.get() + "--"); 


消费 者 的 作用 是 读 取 数据 进行 处 理 。 这 里 ， 数 据 的 读 取 已 经 由 
Disruptor 进 行 封 效 ，onEvent() 方 法 为 框架 的 回调 方法 。 因 此 ， 这 里 只 
需要 简单 地 进行 数据 处 理 即 可 。 


还 需要 一 个 产生 PCData 的 工厂 类 。 它 会 在 Disruptor 系 统 初始 化 
上 时， 构造 所 有 的 缓冲 区 中 的 对 象 实例 (之 前 说 过 Disruptor 会 预先 分 配 


空间 ) : 


public class PCDataFactory implements EventFactory<PCData> 


{ 


public PCData newInstance( ) 


{ 


return new PCData(); 


接着 ， 让 我 们 来 看 一 下 生产 者 ， 它 比 前 面 儿 个 类 稍微 复杂 一 点 : 


01 public class Producer 


02 { 

03 private final RingBuffer<PCData> ringBuffer; 

04 

05 public Producer (RingBuffer<PCData> ringBuffer) 

06 { 

07 this.ringBuffer = ringBuffer; 

08 } 

09 

10 public void pushData(ByteBuffer bb) 

11 { 

2 long sequence = ringBuffer.next(); // Grab the next 
sequence 

13 try 

14 { 

nbs) PCData event = ringBuffer.get(sequence); // Get 


the entry in the Disruptor 

16 // 
for the sequence 

17 event.set(bb.getLong(0)); // Fill with data 

18 } 

19 finally 


21 ringBuffer.publish(sequence) ; 


生产 者 需要 一 个 RingBuffer 的 引用 ， 也 就 是 环形 缓冲 区 。 它 有 一 
个 重要 的 方法 pushData(0) 将 产生 的 数据 推 入 缓冲 区 。 方 法 pushData() 接 
收 一 个 ByteBuffer 对 象 。 在 ByteBuffer 中 可 以 用 来 包装 任何 数据 类 型 。 
这 里 用 来 存储 long 整 数 ，pushData0 的 功能 就 是 将 传 入 的 ByteBuffer 中 
的 数据 提取 出 来 ， 并 装载 到 环形 缓冲 区 中 。 


上 述 第 12 行 代码 ， 通 过 next() 方 法 得 到 下 一 个 可 用 的 序列 号 。 通 过 
序列 号 ， 取 得 下 一 个 空闲 可 用 的 PCData， 并 且 将 PCData 的 数据 设 为 期 
望 值 ， 这 个 值 最 终 会 传递 给 消费 者 。 最 后 ， 在 第 21 行 ， 进 行 数据 发 
布 。 只 有 发 布 后 的 数据 才 会 真正 被 消费 者 看 见 。 


至 此 ， 我 们 的 生产 者 、 消 费 者 和 数据 都 已 经 准备 束 绪 。 只 差 一 个 
统筹 规划 的 主 函 数 将 所 有 的 内 容 整 合 起 来 : 


01 public static void main(String[] args) throws Exception 


02 { 

03 Executor executor = Executors.newCachedThreadPool(); 

04 PCDataFactory factory = new PCDataFactory(); 

05 // Specify the size of the ring buffer, must be power of 
2. 

06 int bufferSize = 1024; 


07 Disruptor <PCData> disruptor = new Disruptor <PCData> 


(factory, 


08 bufferSize, 

09 executor, 

10 ProducerType.MULTI, 

11 new BlockingWaitStrategy() 

12 ); 

is disruptor .handleEventswithWorkerPool ( 
14 new Consumer(), 

15 new Consumer(), 

16 new Consumer(), 

17 new Consumer()); 

18 disruptor.start(); 

19 

20 RingBuf fer <PCData> ringBuffer 
disruptor.getRingBuffer(); 

21 Producer producer = new Producer(ringBuffer ); 
22 ByteBuffer bb = ByteBuffer.allocate(8); 
23 for (long 1 = 0; true; 1++) 

24 { 

25 bb.putLong(0, 1); 

26 producer.pushData(bb); 

27 Thread.sleep(100) ; 

28 System.out.println("add data "+1); 
29 } 


上 述 代 码 第 6 行 ， 设 置 缓 神 区 大 小 为 1024。 显 然 是 2 的 整数 次 需 
一 一 一 个 合理 的 大 小 。 第 7 一 12 创 建 了 disruptor 对 象 。 它 封装 了 整个 
disruptor 库 的 使 用 ， 提 供 了 一 些 便 捷 的 API。 第 13~17 行 ， 设 置 了 用 于 
处 理 数据 的 消费 者 。 这 里 设置 了 4 个 消费 者 实例 ， 系 统 会 为 将 每 一 个 消 
费 者 实例 映 喘 到 一 个 线程 中 ， 也 就 是 这 里 提供 了 4 个 消费 者 线程 。 第 18 
行 ， 启 动 并 初始 化 disruptor 系 统 。 在 第 23 一 29 行 中 ， 由 一 个 生产 者 不 
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生产 者 和 消费 者 正常 工作 。 根 据 Disruptor 的 官方 报告 ，Disruptor 
的 性 能 要 比 BlockingQueue 至 少 高 一 个 数量 级 以 上 。 如 此 诱 人 的 性 能 ， 
当然 值得 我 们 去 党 试 ! 


5.4.3 ”提高 消费 者 的 啊 应 时 间 : 选择 
合适 的 策略 


当 有 新 数 据 在 Disruptor 的 环形 缓冲 区 中 产生 时 ， 消 费 者 如 何 知 道 
这 些 新 产生 的 数据 呢 ? 或 者 说 ， 消 费 者 如 何 监控 缓冲 区 中 的 信息 呢 ? 


为 此 ， 


Disruptor 提 供 了 几 种 策略 ， 这 些 策略 由 WaitStrategy 接 口 进行 封 


闭 ， 主 要 有 以 下 几 种 实现 。 


BlockingWaitStrategy : 这 是 默认 的 策略 。 使 用 
BlockingWaitStrategy 和 使 用 BlockingQueue 是 非常 类 似 的 ， 它 们 
都 使 用 锁 和 条 件 (Condition) 进行 数据 的 监控 和 线程 的 唤醒 。 
为 涉及 到 线程 的 切换 ，BlockingWaitStrategy 人 策略 是 最 节省 
CPU， 但 是 在 高 并 发 下 性 能 表现 最 糟糕 的 一 种 等 每 策略。 
SleepingWaitStrategy: 这 个 策略 也 是 对 CPU 使 用 率 非 常 保守 
的 。 它 会 在 循环 中 不 断 等 竺 数据 。 它 会 移 进行 目 旋 等 待 ， 如 果 
不 成 功 ， 则 使 用 Thread.yield0 让 出 CPU ， 并 最 终 使 用 
LockSupport.parkNanos(1) 进 行 线程 休眠 ， 以 确保 不 占用 太 多 的 
CPU 数 据 。 因 此 ， 这 个 策略 对 于 数据 处 理 可 能 产生 比较 高 的 平 
均 延 时 。 它 比较 适合 于 对 延 时 要 求 不 是 特别 高 的 场合 ， 好 处 是 
它 对 生产 者 线程 的 影响 最 小 。 典 型 的 应 用 场景 是 异步 日 志 。 
YieldingWaitStrategy: 这 个 策略 用 于 低 延 时 的 场合 。 消 费 者 线 
程 会 不 断 循 环 监控 缓冲 区 变化 ， 在 循环 内 部 ， 它 会 使 用 
Thread.yield() 让 出 CPU 给 别 的 线程 执行 时 间 。 如 有 果 你 需要 一 个 
高 性 能 的 系统 ， 并 且 对 延 时 有 较为 严格 的 要 求 ， 则 可 以 考虑 这 
种 策略 。 使 用 这 种 策略 时 ， 相 当 于 你 的 消费 者 线程 变 里 成 为 了 
一 个 内 部 执行 了 Thread.yield() 的 死 循环 。 因 此 ， 你 最 好 有 多 于 
消费 者 线程 数量 的 逻辑 CPU 数量 (这 里 的 逻辑 CPU， 我 指 的 
是 “双核 四 线程 * 中 的 那个 四 线程 ， 否 则 ， 整 个 应 用 程序 名 怕 都 


会 受到 影响 。 


e BusySpinWaitStrategy: 这 个 是 最 疯狂 的 等 待 策 略 了 。 它 就 是 一 
个 死 循 环 ! 消费 者 线程 会 尽 最 大 努力 疯狂 监控 缓冲 区 的 变化 。 
因此 ， 它 会 吃 掉 所 有 的 CPU 资源 。 你 只 有 在 对 延迟 非常 奇 刻 的 
场合 可 以 考虑 使 用 它 (或 者 说 ， 你 的 系统 真 的 非常 繁忙 ) ° 
为 在 这 里 你 等 同 开 启 了 一 个 死人 循环 监控 ， 所 以 ， 你 的 物理 CPU 
数量 必须 要 大 于 消费 者 线程 数 。 注 意 ， 我 这 里 说 的 是 物理 
CPU， 如 采 你 在 一 个 物理 核 上 使 用 超 线程 技术 模拟 两 个 逻辑 
核 ， 另 外 一 个 逻辑 核 显 然 会 受到 这 种 超 密集 计算 的 影响 而 不 能 
iE LF ° 


在 上 面 的 例子 中 ， 使 用 的 是 BlockingWaitStrategy (981147) 。 读 
者 可 以 蔡 换 这 个 实现 ， 体 验 一 下 不 同等 等 策 略 的 鸡 果 。 


5.4.4 CPU Cache 的 优化 : 解决 伪 共 
享 问题 


除了 使 用 CAS 和 提供 了 各 种 不 同 的 等 待 策略 来 提高 系统 的 吞吐 量 
外 。Disruptor 大 有 将 优化 进行 到 搬 的 气势 ， 它 甚至 笑 试 解决 CPU 绥 存 
的 盆 共 至 问题 。 


什么 是 伪 共 享 问题 呢 ? 我 们 知道 ， 为 了 提高 CPU 的 速度 ，CPU 有 
个 高 速 缓存 Cache。 在 高 速 缓存 中 ， 读 写 数 据 的 最 小 单位 为 缓存 行 
(Cache Line) ， 它 是 从 主 存 (memory) 复制 到 缓存 (Cache) 的 最 小 

单位 ， 一 般 为 32 字 节 到 128 字 他。 


如 果 两 个 变量 存放 在 一 个 缓存 行 中 时 ， 在 多 线程 访问 中 ， 可 能 会 


行 在 CPU1 上 的 线程 更 新 了 XX， 那么 CPU2 上 的 缓存 行 就 会 失效 ， 同 一 
行 的 Y 即 使 没有 修改 也 会 变 成 无 效 ， 导 致 Cache 无 法 命中 。 接 着 ， 如 果 
在 CPU2 上 的 线程 更 新 了 Y， 则 导致 CPU1 上 的 缓存 行 又 失效 (此 时 ， 
同一 行 的 X 又 变 得 无 法 访问 ) 。 这 种 情况 反 反 复 复 发 生 ， 无 疑 是 一 个 
洪 在 的 性 能 杀手 。 如 果 CPU 经 常 不 能 命中 缓存 ， 那 么 系统 的 吞吐 量 就 
会 急剧 下 降 。 
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图 5.4 X 和 Y 在 同一 个 缓存 行 中 


为 了 使 这 种 情况 不 发 生 ， 一 种 可 行 的 做 法 整 是 在 Xx 变量 的 前 后 空 
间 都 先 占据 一 定 的 位 置 (把 它 叫 做 padding 吧 ， 用 来 填充 用 的 ) 。 这 
样 ， 当 内 存 被 读 入 缓存 中 时 ， 这 个 缓存 行 中 ， 只 有 X 一 个 变量 实际 是 
有 效 的 ， 因 此 区 不 会 发 生 多 个 线程 同时 修改 缓存 行 中 不 同 变量 而 导致 
变量 全 体 失效 的 情况 ， 如 图 5.5 所 示 。 
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图 5.5 ”变量 X 和 Y 各 占据 一 个 缓冲 行 


为 了 实现 这 个 目的 ， 我 们 可 以 这 么 做 : 


01 public final class FalseSharing implements Runnable { 


02 public final static int NUM_THREADS = 2; // change 

03 public final static long ITERATIONS = 500L * 1000L * 
1000L; 

04 private final int arrayIndex; 

05 

06 private static VolatileLong[] longs = new 


VolatileLong[NUM_ THREADS]; 


07 static { 
08 for (int i = ©; i < longs.length; i++) { 
09 longs[i] = new VolatileLong(); 


10 } 


12 

Ls public FalseSharing(final int arrayIndex) { 

14 this.arrayIndex = arrayIndex; 

15 } 

16 

17 public static void main(final String[] args) throws 


Exception { 


18 final long start = System.currentTimeMillis(); 
19 runTest(); 
20 System.out.println("duration = " + 


(System.currentTimeMillis() - start)); 

21 } 

22 

23 private static void runTest() throws 


InterruptedException { 


24 Thread[] threads = new Thread[NUM_THREADS]; 

25 

26 for (int 1 = 0; i < threads.length; i++) { 

27 threads[i] = new Thread(new FalseSharing(1i)); 
28 } 

29 

30 for (Thread t : threads) { 

31 t.start(); 

32 } 

33 


34 for (Thread t : threads) { 


35 t.join(); 


39 public void run() { 
40 long i = ITERATIONS + 1; 
41 while (9 != --i) { 


42 longs[arrayIndex].value = 1; 


46 public final static class VolatileLong { 
47 public volatile long value = OL; 


48 public long pi, p2, p3, p4, p5, p6,p7; // comment 


这 里 我 们 使 用 两 个 线程 ， 因 为 我 的 计算 机 是 双核 的 ， 大 家 可 以 根 
据 自 己 的 硬件 配置 修改 参数 NUM_THREADS (第 2 行 ) 。 我 们 准备 一 
个 数组 longs (第 6 行 ) ， 数 组 元 素 个 数 和 线程 数量 一 致 。 每 个 线程 都 
会 访问 自己 对 应 的 longs 中 的 元 素 〈 从 第 42 行 、 第 27 行 和 第 14 行 可 以 看 
到 这 一 点 ) 。 


最 后 ， 最 关键 的 一 点 就 是 VolatileLong。 在 第 48 行 ， 准 备 了 7 个 long 
型 变量 用 来 填充 缓存 。 实 际 上 ， 只 有 VolatileLong.value 是 会 被 使 用 


的 。 而 那些 p1、p2 等 仅仅 用 于 将 数组 中 第 一 个 VolatileLong.value 和 第 
二 个 VolatileLong.value 分 开 ， 防 止 它们 进入 同一 个 缓存 行 。 


这 里 ， 我 使 用 JDK7 64 位 的 Java 虚 拟 机 ， 执 行 上 述 程 序 ， 输 出 如 
下 : 


duration = 5207 


这 说 明 系 统 伦 费 了 5 秒 钟 完成 所 有 的 操作 。 如 采 我 注释 挥 第 48 行 ， 
也 就 是 允许 系统 中 两 个 VolatileLong.value 放 置 在 同一 个 缓存 行 中 ， 程 
序 输出 如 下 : 


duration = 13675 
很 明显 ， 第 48 行 的 填充 对 系统 的 性 能 是 非常 有 帮助 的 。 


注意 : 由 于 各 个 JDK 版 本 内 部 实现 不 一 致 ， 在 某 些 JDK 版 本 中 

(比如 JDK 8) ， 会 自动 优化 不 使 用 的 字段 。 这 将 直接 导致 这 种 
padding 的 伪 共 至 解 决 方案 失效 。 更 多 详细 内 容 大 家 可 以 参考 第 6 
章 中 有 关 LongAddr 的 介绍 。 


Disruptor 框 染 充 分 考虑 了 这 个 问题 ， 它 的 核心 组 件 Sequence 会 店 
非常 频繁 的 访问 (每 次 入 队 ， 它 都 会 被 加 1) ， 其 基本 结构 如 下 : 


class LhsPadding 


£ 
protected long p1, p2, p3, p4, p5, p6, p7; 


class Value extends LhsPadding 


protected volatile long value; 


class RhsPadding extends Value 


i 
protected long p9, p10, p11, p12, p13, p14, p15; 
jp 
ublic class Sequence extends RhsPadding{ 
// 省 略 具体 实现 
i 


虽然 在 Sequence 中 ， 主 要 使 用 的 只 有 vaue。 但 是 ， 通 过 
LhsPadding 和 RhsPadding， 在 这 个 value 的 前 后 安置 了 一 些 占 位 空间 ， 
使 得 value 可 以 无 冲突 的 存在 于 缓存 中 。 


此 外 ， 对 于 Disruptor 的 环形 缓冲 区 RingBuffer， 它 内 部 的 数组 是 通 
过 以 下 语句 构造 的 : 


this.entries = new Object[sequencer.getBufferSize() + 2 * 


BUFFER_PAD]; 


大 家 注意 ， 实 际 产生 的 数组 大 小 征 缓冲 区 实际 大 小 再 加 上 两 倍 的 
BUFFER_PAD“。 这 束 相 当 于 在 这 个 数组 的 头 部 和 尾部 两 段 各 增加 了 
BUFFER_PAD 个 填充 ， 使 得 整个 数组 被 载 入 Cache 时 不 会 受到 其 他 变 
量 的 影响 而 失效 。 


5.5 “Future 模式 


Future 模 式 征 多 线程 开发 中 非常 遇见 的 一 种 设计 模式 ， 写 的 核心 
思想 是 异步 调用 。 当 我 们 需要 调用 一 个 函数 方法 时 ， 如 有 果 这 个 函数 执 
行 很 慢 ， 那 么 我 们 就 要 进行 等 等。 但 有 时 候 ， 我 们 可 能 并 不 急 看 要 结 
果 。 因 此 ， 我 们 可 以 让 被 调 者 立即 返回 ， 让 它 在 后 台 慢 慢 处 理 这 个 请 
求 。 对 于 调用 者 来 说 ， 则 可 以 先 处 理 一 些 其 他 任务 ， 在 真正 需要 数据 
的 场合 再 去 尝试 获得 需要 的 数据 。 


Future 模 式 有 点 类 似 在 网 上 买 东 西 。 如 果 我 们 在 网 上 下 单 买 了 一 
个 手机 ， 当 我 们 文 付 完成 后 ， 手 机 并 没有 办 法 立即 送 到 家 里 ， 但 十 在 
电脑 上 会 立即 产生 一 个 订单 。 这 个 订单 就 是 将 来 发 货 或 者 领取 手机 的 
重要 凭证， 这 个 凭证 也 避 是 Future 模 式 中 会 给 出 的 一 个 站 约 。 在 文 付 
活动 结束 后 ， 大 家 不 会 优优 地 等 着 手机 到 来 ， 而 是 可 以 各 忙 各 的 。 而 
这 张 订单 束 成 为 了 商家 配 贷 、 发 从 的 驱动 力 。 当 然 ， 这 一 切 你 并 不 用 
关心 。 你 要 做 的 ， 只 是 在 快递 上 门 时 ， 开 一 下 | 站， 拿 一 下 货 而 已 。 


对 于 Future 模 式 来 说 ， 虽 然 它 无 法 立即 给 出 你 需要 的 数据 。 但 
征 ， 它 会 返回 给 你 一 个 契约 ， 将 来 ， 你 可 以 皂 借 痢 这 个 九 约 去 重新 获 
取 你 需要 的 信息 。 


如 图 5.6 所 示 ， 显 示 了 通过 传统 的 同步 方法 ， 调 用 一 段 比较 耗 时 的 
程序 。 客 户 端 发 出 call 请 求 ， 这 个 请 求 需要 相当 长 一 段 时 间 才 能 返回 。 
客户 端 一 直 等 待 ， 直 到 数据 返回 ， 随 后 ， 再 进行 其 他 任务 的 处 理 。 
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图 5-6 ”传统 串 行 程序 调用 流程 


使 用 Future 模 式 蔡 换 原 来 的 实现 方式 ， 可 以 改进 其 调用 过 程 ， 如 
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图 5-7 ”Future 模式 流程 图 


下 面 的 模型 展示 了 一 个 广义 Future 模 式 的 实现 ， 从 Data_Future 对 
象 可 以 看 到 ， 虽 然 cal 本 号 仍然 需要 很 长 一 段 时 间 处 理 程 序 。 但 是 ， 服 
务 程序 不 等 数据 处 理 完成 便 立 即 返 回 客户 端 一 个 伪造 的 数据 (相当 于 
商品 的 订单 ， 而 不 是 商品 本 映 ) ， 实 现 了 Future 模 式 的 客户 端 在 拿 到 
这 个 返回 结果 后 ， 并 不 急于 对 其 进行 处 理 ， 而 去 调用 了 其 他 业务 逻 
辑 ， 充 分 利用 了 等 待 时 间 ， 这 就 是 Future 模 式 的 核心 所 在 。 在 完成 了 
其 他 业务 逻辑 的 处 理 后 ， 最 后 再 使 用 返回 比较 慢 的 Future 数 据 。 这 
样 ， 在 整个 调用 过 程 中 ， 就 不 存在 无 谓 的 等 得 ， 充 分 利用 了 所 有 的 时 
间 片 段 ， 从 而 提高 系统 的 响应 速度 。 


5.5.1 Future 模式 的 主要 角色 


为 了 让 大 家 能 够 更 清晰 地 认识 Future 模 式 的 基本 结构 。 在 这 里 ， 
我 给 出 一 个 非常 稍 单 的 Future 模 式 的 实现 ， 写 的 主要 参与 者 如 表 5.2 所 


表 5.2 Future 模式 的 主要 参与 者 


参与 者 作用 

Main 系统 启动 ， 调 用 Client 发 出 请 求 

Client 返回 Data 对 象 ， 立 即 返 回 FutureData， 并 开启 ClientThread 线 程 装配 RealData 
Data 返回 数据 的 接口 

FutureData Future 数 据 ， 构 造 很 快 ， 但 是 是 一 个 虚拟 的 数据 ， 需 要 装配 RealData 
RealData 真实 数据 ， 其 构造 是 比较 慢 的 


它 的 核心 结构 如 图 5.8 所 示 。 


FutureData 


- isReady : boolean 


+ setRealData (RealData realData) :void 


Aà ClientThread 
0 0 RealData 
pe i i ~- content : String 
00000 Fu + RealData (String para) 
trueData 人 
OF Data 


Client | 1 0 


+ getContent() : String 


+ request (String queryStr) : Date 7 


11 Main 


图 5.8 Future 模式 结构 图 


5.5.2 Future 模式 的 简单 实现 


在 这 个 实现 中 ， 有 一 个 核心 接口 Data， 这 就 是 客户 端 硕 望 获 取 的 
数据 。 在 Future 模 式 中 ， 这 个 Data 接 口 有 两 个 重要 的 实现 ， 分 别 是 
RealData， 也 就 是 真实 数据 ， 这 就 是 我 们 最 终 需 要 获得 的 ， 有 价值 的 
信息 。 男 外 一 个 就 是 FutureData， 它 束 是 用 来 提取 RealData 的 一 个 “ 订 
单 *。 因 此 FutureData 是 可 以 立即 返回 得 到 的 。 


下 面 是 Data 接 口 : 


public interface Data { 


public String getResult (); 


FutureData3& EW T — C R RR E A RealDatah Re ° CARE ThE 
#2, Boa wE A RealData h Met o Ak, EA LR Re et 
返回 。 当 使 用 FutrueData 的 getResult0 方 法 时 ， 如 果实 际 的 数据 没有 准 
备 好 ， 那 么 程序 就 会 蛆 塞 ， 等 等 RealData 准 备 好 并 注入 到 FutureData 
中 ， 才 最 终 返 回 数据 。 


注意 : FutureData 是 Future 模 式 的 关键 。 它 实际 上 是 真实 数据 
RealData 的 代理 ， 封 效 了 获取 RealData 的 等 待 过 程 。 


public class FutureData implements Data { 


protected RealData realdata = null; //FutureData 


是 RealData 的 包装 
protected boolean isReady = false; 
public synchronized void setRealData(RealData realdata) { 
if (isReady) { 


return; 


this.realdata = realdata; 


isReady = true; 


notifyAll1(); //RealData č 
经 被 注入 ， 通 知 getResult() 
} 
public synchronized String getResult() { // 会 等 待 
RealData 构 造 完 成 


while (!isReady) { 


try { 
wait(); J/-BoSe, A 


道 RealData 被 注入 


} catch (InterruptedException e) { 
} 
} 


return realdata.result; //WRealData 


RealData 是 最 终 需 要 使 用 的 数据 模型 。 它 的 构造 很 慢 。 在 这 里 ， 
使 用 sleep0) 函 数 模 拟 这 个 过 程 ， 位 单 地 模拟 一 个 字符 串 的 构造 。 


public class RealData implements Data { 
protected final String result; 
public RealData(String para) { 
/V/RealData 的 构造 可 能 很 慢 ， 需 要 用 户 等 待 很久， 这 里 使 用 Sleep 模拟 


StringBuffer sb=new StringBuffer(); 
ror “(Ant L = ©; Pb < 10) nr) A 
sb.append(para); 
try { 
// 这 里 使 用 Sleep， 代 蔡 一 个 很 慢 的 操作 过 程 
Thread.sleep(100) ; 


} catch (InterruptedException e) { 
} 
} 
result =sb.toString(); 
} 
public String getResult() { 


return result; 


接 下 来 就 是 我 们 的 客户 端 程 序 ，Client 主 要 实现 了 获取 
FutureData， 并 开启 构造 RealData 的 线程 。 并 在 接受 请 求 后 ， 很 快 的 返 
回 FutureData 。 注 意 ， 它 不 会 等 符 数 据 真 的 构造 完毕 再 返回 ， 而 是 立即 
返回 FutureData， 即 使 这 个 时 候 FutureData 内 并 没有 真实 数据 。 


public class Client { 
public Data request(final String queryStr) { 
final FutureData future = new FutureData(); 
new Thread() { 


public void run() { // RealData 的 构 


// 所 以 在 单独 的 线程 


中 进行 
RealData realdata = new RealData(queryStr); 
future.setRealData(realdata); 
} 
}.start(); 
return future; // FutureData 会 
被 立即 返回 
} 
} 


最 后 ， 就 是 我 们 的 主 范 数 Main， 它 主要 负责 调用 Client 发 起 请 
求 ， 并 消费 返回 的 数据 。 


public static void main(String[] args) { 


Client client = new Client(); 


// 这 里 会 立即 返回 ， 因 为 得 到 的 是 FutureData 而 不 是 RealData 


Data data = client.request("name"); 


System.out,printLn(" 请 求 完 毕 " ) ， 
try { 
// 这 里 可 以 用 一 个 Sleep 代替 了 对 其 他 业务 逻辑 的 处 理 
// 在 处 理 这些 业 务 逻 辑 的 过 程 中 ，RealData 被 创建 ， 从 而 充分 利用 了 等 待 时 间 
Thread.sleep(2000); 


} catch (InterruptedException e) { 


t 
// 使 用 真实 的 数据 


System.out.printin("2Gm = " + data.getResult()); 


5.5.3 JDK 中 的 Future 模 式 


Future 模 式 是 如 此 常用 ， 因 此 JDK 内 部 已 经 为 我 们 准备 好 了 一 套 完 
整 的 实现 。 显 然 ， 这 个 实现 要 比 我 们 前 面 提出 的 方案 复杂 得 多 。 在 这 
里 ， 我 们 将 简单 向 大 家 介绍 一 下 它 的 使 用 方式 。 


首 完 ， 让 我 们 看 一 下 Future 模 式 的 基本 结构 ， 如 图 5.9 所 示 。 其 中 
Future 接 口 就 类 似 于 前 文 描述 的 订单 或 者 说 是 契约 。 通 过 它 ， 你 可 以 
得 到 真实 的 数据 。RunnableFuture 继 承 了 Future 和 Runnable 两 个 接口 ， 
其 中 run0 方 法 用 于 构造 真实 的 数据 。 它 有 一 个 具体 的 实现 FutureTask 
类 。FutureTask 有 一 个 内 部 类 Sync， 一些 实质 性 的 工作 ， 会 委托 Sync 类 
实现 。 而 Sync 类 最 终 会 调用 Callable 接 口 ， 完 成 实际 数据 的 组 装 工作 。 


- © Future i 
~ Runnable Futurel 0 0 0 
00000 
| + get() :void 
+ run() :void A 
© RunnableFuture 
+ run() :void 
FutureTask Sync © Callable 
+ get() :V ~ # innerRun () :void + call() :V 
+ run() :void = E z 


图 5.9_JDK 内 置 的 Future 模 式 


Callable 接 口 只 有 一 个 方法 call0， 它 会 返回 需要 构造 的 实际 数据 。 
这 个 Callable 接 口 也 是 这 个 Future 框 架 和 应 用 程序 之 间 的 重要 接口 。 如 
果 我 们 要 实现 目 己 的 业务 系统 ， 通 常 需 要 实现 上 自己 的 Callable 对 象 。 此 
外 ，FutureTask 类 也 与 应 用 密切 相关 ， 通 常 ， 我 们 会 使 用 Callable 实 例 
构造 一 个 FutureTask 实 例 ， 并 将 它 提交 给 线程 池 。 


下 面 我 们 将 展示 这 个 内 置 的 Future 模 式 的 使 用 : 


01 public class RealData implements Callable<String> { 


02 private String para; 

03 public RealData(String para){ 

04 this.para=para; 

05 } 

06 @Override 

07 public String call() throws Exception { 
08 

09 StringBuffer sb=new StringBuffer(); 
10 ror (dme i = 0p a < 10 iam) 4 

11 sb.append(para); 

12 try { 

13 Thread.sleep(100); 

14 } catch (InterruptedException e) { 
15 } 

16 } 

17 return sb.toString(); 

18 } 


上 述 代 码 实现 了 Callable 接 口 ， 它 的 call0 方 法 会 构造 我 们 需要 的 真 
实数 据 并 返回 。 当 然 这 个 过 程 可 能 是 缓慢 的 ， 这 里 使 用 Thread.sleep() 
模拟 它 : 


01 public class FutureMain { 
02 public static void main(String[] args) throws 
InterruptedException, ExecutionException { 


03 // 构 造 FutureTask 


04 FutureTask<String> future = new FutureTask<String 
>(new RealData("a")); 
05 ExecutorService executor = 


Executors.newFixedThreadPool(1); 


06 // 执 行 FutureTask， 相 当 于 上 例 中 的 client.request("a") 发 
送 请 求 

07 // 在 这 里 开启 线程 进行 RealData 的 call( ) 执 行 

08 executor ,Submit(future ) ， 

09 

10 System,out.printlLn(" 请 求 完毕 " ) ， 

11 try { 

12 // 这 里 依然 可 以 做 额外 的 数据 操作 ， 这 里 使 用 sleep 代 巷 其 他 业务 逻辑 
的 处 理 

13 Thread.sleep(2000); 

14 } catch (InterruptedException e) { 

15 } 

16 // 相 当 于 5.5.2 节 中 得 data.getResult ()， 取 得 call( ) 方 法 的 返 
回 值 


17 // 如 采 此 时 cal1( ) 方 法 没有 执行 完成 ， 则 依然 会 等 待 


18 System,out,println(" 数 据 = " + future.get()); 


上 述 代 人 码 束 是 使 用 Future 模 式 的 典型 。 第 4 行 ， 构 造 了 FutureTask 

对 象 实例 ， 表 示 这 个 任务 是 有 返回 值 的 。 构 造 FutureTask 时 ， 使 用 

ae 告诉 FutureTask 我 们 需要 的 数据 应 该 如 何 产 生 。 接 着 再 

第 8 行 ， 将 FutureTask 提 区 给 线程 池 。 显 然 ， 作 为 一 个 简单 的 任务 提 

区， 这 里 必然 是 立即 返回 的 ， 因 此 程序 不 会 阻塞 。 接 下 来 ， 我 们 不 用 

A/D SLR AMAL” Sey 。 可 以 去 做 一 些 额外 的 事情 ， 然 后 在 需要 的 时 
候 可 以 通过 Future.getO (第 18 行 ) 得 到 实际 的 数据 。 


除了 基本 的 功能 外 ，JDK 还 为 Future 接 口 提供 了 一 些 简单 的 控制 功 
能 : 


boolean cancel(boolean mayInterruptIfRunning ) ; // 取 
消 任务 

boolean isCancelled(); // 是 
否 已 经 取消 
boolean isDone(); // = 
ATER 

V get() throws InterruptedException, ExecutionException; // 取 
得 返回 对 象 

V get(long timeout, TimeUnit unit) // 
得 返回 对 象 ， 可 以 设置 超时 时 间 


5.6 ”并 行 流水 线 


并 发 算法 虽然 可 以 充分 发 挥 多 核 CPU 的 性 能 。 但 不 笠 的 是 ， 并 非 
所 有 的 计算 都 可 以 改造 成 并 发 的 形式 。 那 什么 样 的 算法 是 无 法 使 用 并 
发 进行 计算 的 呢 ? MARN, DTG RICHER EAS Ae 
法 完美 并 行 化 的 。 


假如 现在 有 两 个 数 ，B 和 C。 如 采 我 们 要 计算 (B+C)*B/2， 那 么 这 
个 运行 过 程 承 是 无 法 并 行 的。 原因 是 ， 如 果 B+C 没 有 执行 完成 ， 则 永 
远 算 不 出 (B+C)*B， 这 束 是 数据 相关 性 。 如 有 果 线 程 执行 时 ， 所 和 需 的 数 
据 存 在 这 种 依赖 天 系 ， 那 么 ， 束 没有 办 法 将 它们 完 类 的 并 行 化 。 如 图 
5.10 所 示 ， 诠 释 了 这 个 道理 。 


(B+C)*xB/2 


AÉ BHC AR A 


图 5.10”(B+C)*B/2 无 法 并 行 化 


那 遇 到 这 种 情况 时 ， 有 没有 什么 补救 措施 呢 ? 答案 是 肯定 的 ， 那 
就 是 借鉴 日 常生 产 中 的 流水 线 思想 。 


比如 ， 现 在 要 生产 一 批 小 玩偶 。 小 玩偶 的 制作 分 为 四 个 步 台 ， 第 
BAR AK, OBER ERROR, Bo, AaB se aM 
Sto EPPA RAR, BA, AT ee he T° A TIAR] 
作 玩 具 的 进度 ， 我 们 不 可 能 叫 四 个 人 同时 加 工 一 个 玩具 ， 因 为 这 四 个 
步骤 有 着 挛 重 的 依赖 关系 。 如 采 没 有 身体 ， 怠 没有 地 方 安 痛 四 肢 ， 如 
果 没 有 组 洲 完 成， 避 C 不 能 穿 衣服 ， 如 采 没 有 穿 上 衣服 ， 束 不 能 包装 发 
货 。 因 此 ， 找 四 个 人 来 做 一 个 玩偶 是 至 无 意义 的 。 


但 是 ， 如 果 你 现在 要 制作 的 不 是 1 只 玩偶 ， 而 是 1 万 只 玩偶 ， 那 情 
况 束 不 同 了 。 你 可 以 找 四 个 人 ， 第 一 个 人 只 负责 组 洲 映 体 ， 完 成 后 交 
给 第 二 个 人 ; 第 二 个 人 只 人 负责 安 准 头 部 和 四 胶 ， 交 付 第 三 人 ; 第 三 人 
只 负责 穿 衣 服 ， 并 交付 第 四 人 ;， 第 四 人 只 负责 包装 发 货 。 这 样 所 有 人 
都 可 以 一 起 工作 ， 共 同 完成 任务 ， 而 整个 时 间 周 期 也 能 缩短 到 原来 的 
1/4 左 右 ， 这 就 是 流水 线 的 思想 。 一 旦 流水 线 满载 ， 每 次 只 需要 一 步 

(假设 一 个 玩偶 需要 四 步 ) 就 可 以 产生 一 个 玩偶 ， 如 图 5.11 所 示 。 
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图 5.11 ”使 用 流水 线 生 产 玩 偶 


类 似 的 思想 可 以 借鉴 到 程序 开发 中 。 即 使 (B+C)*B/2 无 法 并 行 ， 但 
是 如 果 你 需要 计算 一 大 堆 B 和 C 的 值 ， 你 依然 可 以 将 它 流水 化 。 首 先 将 
计算 过 程 拆 分 为 三 个 步 又 : 


Pl:A=B+C 
P2:D= AxB 
P3:D=D/2 


上 述 步骤 中 P1、P2 和 了 P3 均 在 单独 的 线程 中 计算 ， 并 且 每 个 线程 上 只 
负责 自己 的 工作 。 此 时 ，P3 的 计算 结果 就 是 最 终 需 要 的 答案 。 


果 输 入 给 P2。P2 求 乘积 后 输入 给 


P1 接 收 B 和 C 的 值 ， 并 求 和 ， 将 结 
日 这 条 流水 线 建立 ， 只 需要 一 个 计算 


P3。P3 将 D 除 以 2 得 到 最 终 值 。 一 
步骤 就 可 以 得 到 (B+C)*B/2 的 结果 。 


为 了 实现 这 个 功能 ， 我 们 需要 定义 一 个 在 线程 间 携 带 结果 进行 信 
思 交 换 的 载体 : 


public class Msg { 
public double i; 
public double j; 
public String orgStr=null; 


P1 计 算 的 是 加 法 : 


01 public class Plus implements Runnable { 
02 public static BlockingQueue <Msg > bq=new 


LinkedBlockingQueue<Msg>(); 


03 @Override 


04 public void run() { 

05 while(true) { 

06 BY 

07 Msg msg=bq.take(); 

08 msg.j=msg.i+msg.j; 

09 Multiply.bq.add(msg); 
10 } catch (InterruptedException e) { 
11 } 

12 } 

i } 

14 } 


上 述 代 码 中 ，P1 取 得 封装 了 两 个 操作 数 的 Msg， 并 进行 求 和 ， 将 


结果 传递 给 乘法 线程 P2 (BOT) 。 当 没有 数据 需要 处 理 时 ，P1 进 行 
等 等。 


P2 计 算 乘法 : 


01 public class Multiply implements Runnable { 
02 public static BlockingQueue<Msg> bq 


LinkedBlockingQueue<Msg>(); 


03 

04 @Override 

05 public void run() { 
06 while (true) { 
07 try { 


08 Msg msg = bq.take(); 


new 


09 msg.i = msg.i * msg.j; 

10 Div.bq.add(msg) ; 

11 } catch (InterruptedException e) { 
12 Í 


和 P1 非 常 类 似 ，P2 计 算 相 乘 结果 后 ， 将 中 间 结 果 传 递 给 除法 线程 
P3 ° 
P3 计 算 除 法 : 


01 public class Div implements Runnable { 
02 public static BlockingQueue<Msg> bq = new 


LinkedBlockingQueue<Msg>(); 


03 

04 @Override 

05 public void run() { 

06 while (true) { 

07 try { 

08 Msg msg = bq.take(); 

09 msg.i = msg.i / 2; 

10 System.out.printin(msg.orgStr + "=" + 
msg.1); 

ial } catch (InterruptedException e) { 
12 } 


13 } 


14 } 
15 } 


P3 将 结果 除 以 2 后 输出 最 终 的 结 采 。 


最 后 古 提 交 任 务 的 主线 程 ， 这 里 ， 我 们 提交 100 万 个 请 求 ， 让 线程 
组 进行 计算 : 


01 public class PStreamMain { 


02 public static void main(String[] args) { 
03 new Thread(new Plus()).start(); 

04 new Thread(new Multiply()).start(); 

05 new Thread(new Div()).start(); 

06 

07 for (aime L = 1) 4 <S 10007 ara) ( 

08 for (int j = 1; j <= 1000; j++) { 
09 Msg msg = new Msg(); 

10 msg.i = 1; 

11 msg.j = j; 

12 MSG ON ol SED GG ak r ich egy aie ests dn oe, 
1/2" 

13 Plus.bq.add(msg); 

14 } 

15 } 

16 } 


ees 


上 述 代码 第 13 行 ， 将 数据 提交 给 P1 加 法 线程 ， 开 局 流水 线 的 计 
算 。 在 多 核 或 者 分 布 式 场景 中 ， 这 种 设计 思路 可 以 有 效 地 将 有 依赖 关 
系 的 操作 分 配 在 不 同 的 线程 中 进行 计算 ， 尽 可 能 利用 多 核 优势 。 


5.7 ”并行 搜索 


搜索 是 几乎 每 一 个 软件 都 必 不 可 少 的 功能 。 对 于 有 序数 据 ， 通 常 
可 以 采用 二 分 查找 法 。 对 于 无 序数 据 ， 则 只 能 换个 查找 。 在 本 和 中 ， 


我 们 将 讨论 有 关 并 行 的 无 序数 组 的 搜索 实现 。 


给 定 一 个 数组 ， 我 们 要 得 找 满足 条 件 的 元 素 。 对 于 串 行 程序 来 
说 ， 只 要 裔 历 一 下 数组 就 可 以 得 到 结果 。 但 如 采 要 使 用 并 行 方 式 ， 则 
需要 额外 增加 一 些 线程 间 的 通信 机 制 ， 使 各 个 线程 可 以 有 效 地 运行 。 


一 种 简单 的 集 略 就 是 将 原始 数据 集合 按照 期 望 的 线程 数 进行 分 
割 。 如 采 我 们 计划 使 用 两 个 线程 进行 搜索 ， 那 么 殉 可 以 把 一 个 数组 或 
集合 分 割 成 两 个 。 每 个 线程 各 目 独立 搜索 ， 当 其 中 有 一 个 线程 找到 数 
据 后 ， 立 即 返回 结果 即 可 。 


现在 假设 有 一 个 整 型 数组 ， 我 们 需要 查找 数组 内 的 元 素 : 


static int[] arr; 


定义 线程 池 、 线 程 数 量 以 及 存放 结果 的 变量 result。 在 result 中 ， 我 
们 会 保存 符合 条 件 的 元 聚 在 ar 数组 中 的 下 标 。 黑 认为 -1， 表 示 没 有 找 
到 给 定 元 素 。 
static ExecutorService pool = Executors.newCachedThreadPool(); 


static final int Thread_Num=2; 


static AtomicInteger result=new AtomicInteger(-1); 


并 发 搜索 会 要 求 每 个 线程 查找 arr 中 的 一 段 ， 因 此 ， 搜 索 范 数 必须 
旨 定 线程 需要 搜索 的 起 始 和 结束 位 置 : 


01 public static int search(int searchValue,int beginPos, int 


endPos) { 

02 int i=0; 

03 for(i=beginPos;i<endPos;i++){ 

04 if(result.get() >=0){ 

05 return result.get(); 

06 } 

07 if(arr[i] == searchValue) { 

08 // 如 果 设 置 失败 ， 表 示 其 他 线程 已 经 完 找 到 了 
09 if(!result.compareAndSet(-1, 1)){ 
10 return result.get(); 

11 } 

12 return i; 

13 } 

14 } 

15 return -1; 

16 } 


上 述 代 码 第 4 行 ， 首 先 通过 result 判 断 是 否 已 经 有 其 他 线程 找到 了 
需要 的 结 有 末 。 如 采 已 经 找到 ， 则 立即 返回 不 再 进行 查找 。 如 果 没 有 找 
到 ， 则 进行 下 一 步 搜 索 。 第 7 行 代码 成 立 则 表示 当前 线程 找到 了 需要 的 
数据 ， 那 么 就 会 将 结果 保存 到 result 变 量 中 。 这 里 使 用 CAS 操 作 ， 如 果 
设置 失败 ， 则 表示 其 他 线程 已 经 和 多 我 一 步 找到 了 结果 。 因 此 ， 可 以 无 
视 失 败 的 情况 ， 找 到 结果 后 ， 进 行 返回 。 


定义 一 个 线程 进行 查找 ， 它 会 调用 前 面 的 pSearch0) 方 法 : 


01 public static class SearchTask implements Callable<Integer> 


{ 

02 int begin, end, searchValue; 

03 public SearchTask(int searchValue, int begin, int end) { 
04 this.begin=begin; 

05 this.end=end; 

06 this.searchValue=searchValue; 

07 } 

08 public Integer call(){ 

09 int re= search(searchValue, begin, end); 
10 return re; 

11 } 

a2. } 


最 后 是 pSearch(O 并 行 得 找 函 数 ， 它 会 根据 线程 数量 对 arr 数 组 进行 
划分 ， 并 建立 对 应 的 任务 提交 给 线程 池 处 理 : 


01 public static int pSearch(int searchValue ) throws 


InterruptedException, 


ExecutionException{ 
02 int subArrSize=arr.length/Thread_Num+1; 
03 List<Future<Integer>> re=new ArrayList<Future< 


Integer>>(); 
04 for(int 1=0;i<arr.length;i+=subArrSize) { 
05 int end = i+subArrSize; 


06 if(end>=arr.length)end=arr.length; 


07 re.add( pool. submit (new 


SearchTask(searchValue,i,end))); 


08 } 

09 for(Future<Integer> fu:re){ 

10 if(fu.get()>=0)return fu.get(); 
11 } 

12 return -1; 

13 } 


上 述 代 码 中 使 用 了 JDK 内 置 的 Future 模 式 ， 其 中 第 4~8 行 将 原始 类 
组 arr 划 分 为 若干 段 ， 并 根据 划分 结果 建立 子 任务 。 每 一 个 子 任务 都 会 
返回 一 个 Future 对 象 ， 通 过 Future 对 象 可 以 获得 线程 组 得 到 的 最 终结 
果 。 在 这 里 ， 由 于 线程 之 间 通 过 result 共 享 彼此 的 信息 ， 因 此 只 要 当 一 
个 线程 成 切 返 回 后 ， 其 他 线程 都 会 立即 返回 。 因 此 ， 不 会 出 现 由 于 排 
在 前 面 的 任务 长 时 间 无 法 结束 而 导致 整个 搜索 结果 无 法 立即 获取 的 情 
部 o 


5.8 ”并 行 排序 


排序 是 一 项 非常 第 用 的 操作 。 你 的 应 用 程序 在 运行 时 ， 可 能 无 时 
无 刻 不 在 进行 排序 操作 。 排序 的 算法 有 很 多 ， 但 在 这 里 我 并 不 打算 一 
一 介绍 它们 。 对 于 大 部 分 排序 算法 来 说 ， 都 是 串 行 执行 的 。 当 排序 元 
素 很 多 时 ， 寿 使 用 并 行 算 法 代替 串 行 算法 ， 显 然 可 以 更 加 有 效 地 利用 
CPU。 但 将 串 行 算法 改造 成 并 行 算法 并 非 易 事 ， 甚 至 会 极 大 地 增加 原 
有 算法 的 复杂 度 。 在 这 里 ， 我 将 介绍 几 种 相对 人 簿 单 的 ， 但 是 也 足以 让 
人 脑 洞 大 开 的 平行 排序 算法 。 


分 离 数据 相关 性 : 奇偶 交换 排 
了 


在 介绍 奇偶 排序 前 ， 首 先 让 我 们 看 一 下 熟悉 的 冒 泡 排 序 。 在 这 
里 ， 假 设 我 们 需要 将 数组 进行 从 小 到 大 的 排序 。 冒 泡 排 序 的 操作 很 类 
似 水 中 的 起 泡 上 浮 ， 在 冒 泡 排序 的 执行 过 程 中 ， 如 采 数 据 较 小 ， 它 整 
会 逐步 被 交换 到 前 面 去 ， 相 反 ， 对 于 大 的 数 子 ， 则 会 下 沉 ， 交 换 到 数 
组 的 末尾 。 


冒 泡 排序 的 一 般 算 法 如 下 : 


01 public static void bubbleSort(int[] arr) { 

02 for (int i = arr.length - 1; i > 0; i--) { 
03 Tor (ime J = © J < 1 Jr) { 

04 if (arr[j] > arr[j + 1]) { 


05 int temp = arr[j]; 
06 arri 三 arm + 1I; 
07 arr[j + 1] = temp; 
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A512 ” 冒 泡 排序 迭代 过 程 


大 家 可 以 看 到 ， 在 每 次 迭代 的 交换 过 程 中 ， 由 于 每 次 交换 的 两 个 
元 素 存 在 数据 冲突 ， 对 于 每 个 元 素 ， 它 既 可 能 与 前 面 的 元 素 区 换 ， 也 
可 能 和 后 面 的 元 素 交 换 ， 因 此 很 难 直 接 改造 成 并 行 算 法 。 


如 果 能 够 解 开 这 种 数据 的 相关 性 ， 就 可 以 比较 容易 地 使 用 并 行 算 
法 来 实现 类 似 的 排序 。 奇 侦 交 换 排 友 束 是 基于 这 种 思想 的 。 


对 于 奇偶 交换 排序 来 说 ， 它 将 排序 过 程 分 为 两 个 阶段 ， 奇 交换 和 
偶 交 换 。 对 于 奇 交换 来 说 ， 它 总 是 比较 奇数 索引 以 及 其 相 邻 的 后 续 元 
素 。 而 侦 交 换 总 是 比较 偶数 索引 和 其 相 邻 的 后 续 元 素 。 并 且 ， 奇 交换 
和 侦 交换 会 成 对 出 现 ， 这 样 才能 保证 比较 和 交换 涉及 到 数组 中 的 每 一 
个 元 素 。 


奇偶 交换 的 迭代 示意 图 如 图 5.13 所 示 。 
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图 5.13 ”奇偶 交换 迭代 示意 图 


可 以 看 到 ， 由 于 将 整个 比较 交换 独立 分 割 为 奇 阶段 和 偶 阶 段 。 这 
就 使 得 在 每 一 个 阶段 内 ， 所 有 的 比较 和 交换 是 没有 数据 相关 性 的 。 
此 ， 每 一 次 比较 和 区 换 都 可 以 独立 执行 ， 也 吏 可 以 并 行 化 了 。 


下 面 古 奇偶 交换 排序 的 串 行 实现 : 


01 public static void oddEvenSort(int[] arr) { 
02 int exchFlag = 1, start = 0; 

03 while (exchFlag == 1 || start == 1) { 
04 exchFlag = 0; 


05 for (int i = start; i < arr.length - 1; i += 2) { 


06 ir (arria > arria e Ly a 
07 int temp = arr[i]; 
08 arr[i] = arr[i + 1]; 
09 arr[i + 1] = temp; 
10 exchFlag = 1; 

11 } 

12 } 

13 if (start == 0) 

14 start = i; 

15 else 

16 start = 0; 

17 } 

18 } 


其 中 ，exchFlag 用 来 记录 当前 送 代 是 否 发 生 了 数据 交换 ， 而 start 变 
量 用 来 表示 是 奇 交换 还 是 偶 交 换 。 和 初始 时 ，start 为 0， 表 示 进 行 侦 交 
换 ， 每 次 迭代 结束 后 ， 切 换 start 的 状态 。 如 采 上 一 次 比较 交换 发 生 了 
数据 交换 ， 或 者 当前 正在 进行 的 是 奇 交换 ， 循 环 就 不 会 俘 止 ， 直 到 程 
序 不 再 发 生 交 换 ， 并 且 当 前 进行 的 是 偶 交换 为 止 (表示 奇偶 交换 已 经 
成 对 出 现 ) 。 


上 述 代 码 虽 然 是 串 行 代码 ， 但 是 已 经 可 以 很 方便 地 改造 成 并 行 模 
式 : 


01 static int exchFlag=1; 
02 static synchronized void setExchFlag(int v){ 


03 exchFlag=v; 


04 } 


05 static synchronized int getExchFlag(){ 


06 
ae 
08 


return exchFlag; 


09 public static class OddEvenSortTask implements Runnable{ 


10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 


int 1; 


CountDownLatch latch; 


public OddEvenSortTask(int i,CountDownLatch latch) { 


this.1i=1; 
this.latch=latch; 
} 
@Override 
public void run() { 
if (arr[i] > arr[i + 1]) { 
int temp = arr[i]; 
arr[i] = arr[i + 1]; 
arr[i + 1] = temp; 
setExchFlag(1); 
} 


latch.countDown(); 


public static void pOddEvenSort(int[ ] arr) 


InterruptedException { 


28 
29 


int start = 0; 


while (getExchFlag() == || start == 1) { 


throws 


30 setExchFlag(0); 
31 // 偶 数 的 数组 长 度 ， 当 start 为 1 时 ， 只 有 len/2-1 个 线程 


32 CountDownLatch latch = new 


CountDownLatch(arr.length/2-(arr.length%2==0?start:0)); 


33 for (int i = start; i < arr.length - 1; i += 2) { 
34 pool.submit(new OddEvenSortTask(i, latch) ); 
35 } 

36 // 等 竺 所 有 线程 结束 

37 latch.await(); 

38 if (start == 0) 

39 start = 1; 

40 else 

41 start = 0; 

42 } 

43 } 


上 述 代 码 第 9 行 ， 定 义 了 奇偶 排序 的 任务 类 。 该 任务 的 主要 工作 是 
进行 数据 比较 和 必要 的 交换 (1B ~ 2377) 。 并 行 排序 的 主体 是 
pOddEvenSort() 方 法 ， 它 使 用 CountDownLatch 记 了 如 线程 数量 ， 对 于 每 
一 次 迭代 ， 使 用 单独 的 线程 对 每 一 次 元 素 比 较 和 交换 进行 操作 。 在 下 
一 次 迭代 开始 前 ， 必 须 等 待 上 一 次 从 代 所 有 线程 的 完成 。 


5.8.2 ”改进 的 揪 入 排序 : 硕 尔 排序 


插入 排序 也 是 一 种 很 常用 的 排序 算法 。 它 的 基本 思想 是 ， 一 个 未 
排序 的 数组 (当然 也 可 以 是 链表 ) 可 以 分 为 两 个 部 分 ， 前 半 部 分 是 已 


经 排序 的 ， 后 半 部 分 是 未 排序 的 。 在 进行 排序 时 ， 只 需要 在 未 排序 的 
部 分 中 选择 一 个 元 素 ， 将 其 插入 到 前 面 有 序 的 数组 中 即 可 。 最 终 ， 示 
排序 的 部 分 会 越 来 越 少 ， 直 到 为 0， 那 么 排序 吏 完 成 了 。 初 始 时 ， 可 以 
假设 已 排序 部 分 区 是 第 一 个 元 素 。 


插入 排序 的 几 次 迭代 示意 如 图 5.14 所 示 。 
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图 5.14 ”插入 排序 示意 图 


插入 排序 的 实现 如 下 所 示 : 


01 public static void insertSort(int[] arr) { 


02 int length = arr.length; 

03 int j, i, key; 

04 for (i = 1; i < length; i++) { 
05 //key 为 要 准备 插入 的 元 素 

06 key = arr[i]; 


07 TeS e i 


08 while (j >= 0 && arr[j] > key) { 


09 arr[j + 1] = arr[j]; 
10 J 

11 } 

2 // 找 到 合适 的 位 置 插入 Key 

LS arr[j + 1] = key; 

14 } 

Ts 


上 述 代 码 第 6 行 ， 提 取 要 准备 插入 的 元 素 (也 就 是 未 排序 序列 中 的 
第 一 个 元 素 ) 。 接 着 ， 在 已 排序 队列 中 找到 这 个 元 素 的 插入 位 置 (第 8 
~104T) ， 并 进行 插入 (第 13 行 ) 即 可 ° 


简单 的 插入 排序 是 很 难 并 行 化 的 。 因 为 这 一 次 的 数据 插入 依赖 于 
上 一 次 得 到 的 有 序 序列 ， 因 此 多 个 步 又 之 间 无 法 并 行 。 为 此 ， 我 们 可 
以 对 插入 排序 进行 扩展 ， 这 束 是 希 尔 排序 。 


希 尔 排 序 将 整个 数组 根据 间隔 h 分 割 为 耕 干 个 子 数组 。 了 于 数组 相互 
罕 插 在 一 起 ， 每 一 次 排序 时 ， 分 别 对 每 一 个 子 数组 进行 排序 。 如 图 
5.15 所 示 ， 当 h 为 3 时 ， 硕 尔 排 序 将 整个 数组 分 为 交织 在 一 起 的 三 个 子 
数组 。 其 中 ， 所 有 的 方块 为 一 个 子 数组 ， 所 有 的 圆 形 、 三 角形 分 别 组 
成 另外 两 个 子 数 组 。 每 次 排序 时 ， 总 是 交换 间隔 为 h 的 两 个 元 素 。 
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图 5.15”h=3 时 的 数组 分 割 


在 每 一 组 排序 完成 后 ， 可 以 递减 h 的 值 ， 进 行 下 轮 更 加 精细 的 排 
序 。 直 到 h 为 1， 此 时 等 价 于 一 次 插入 排序 。 


希 尔 排序 的 一 个 主要 优点 是 ， 即 使 一 个 较 小 的 元 素 在 数组 的 末 
尾 ， 由 于 每 次 元 素 移 动 都 以 h 为 间隔 进行 ， 因 此 数组 末尾 的 小 元 素 可 以 
在 很 少 的 交换 次 数 下 ， 束 被 置 换 到 最 接近 元 素 最 终 位 置 的 地 方 。 


下 面 是 布尔 排序 的 串 行 实现 : 


01 public static void shellSort(int[] arr) { 


02 // 计算 出 最 大 的 h 值 

03 Me M = ie 

04 while (h <= arr.length / 3) { 

05 Bear g e le 

06 } 

07 while (h > 0) { 

08 ror (ime L = m i < arr Lengen, i) 4 
09 if (arr[i] < arr[i = h]) { 

10 int tmp = arr[i]; 

11 iNe fi S= L- Mi 

12 while (j >= © && arr[j] > tmp) { 
13 arr[j + h] = arr[j]; 

14 j -=h; 

15 } 

16 arr[j + h] = tmp; 

17 } 

18 } 


19 // 计算 出 下 一 个 h 值 


20 h= (h - 1) / 3; 


上 述 代 码 第 4~6 行 ， 计 算 一 个 合适 的 h 值 ， 接 着 正式 进行 希 尔 排 
序 。 第 8 行 的 for 循 环 进行 间隔 为 h 的 插入 排序 ， 每 次 排序 结束 后 ， 递 减 
ph 的 值 〈 第 20 行 ) 。 直 到 h 为 1， 退 化 为 插入 排序 。 


很 显然 ， 布 尔 排序 每 次 都 针对 不 同 的 子 数组 进行 排序 ， 各 个 子 数 
组 之 间 是 完全 独立 的 。 因 此 ， 很 容易 改写 成 并 行程 序 : 


01 public static class ShellSortTask implements Runnable { 


02 int i = 0; 

03 int h = 0; 

04 CountDownLatch 1; 

05 

06 public ShellSortTask(int i, int h, CountDownLatch latch) 
07 this.i = 1; 

08 this.h = h; 

09 this.1 = latch; 

10 } 

11 

12 @Override 

13 public void run() { 

14 if (arr[i] < arr[i - h]) { 
站 5 int tmp = arr[il]; 


16 Tn g doh; 


17 while (j >= 0 && arr[j] > tmp) { 


18 arr[j + h] arr[j]; 

19 jJ -= m; 

20 } 

21 arr[j + h] = tmp; 

22 } 

23 l.countDown(); 

24 } 

25. } 

26 

2a public static void pShellSort(int[ ] arr) throws 
InterruptedException { 

28 // 计算 出 最 大 的 h 值 

29 dE M= e 

30 CountDownLatch latch null; 

31 while (h <= arr.length / 3) { 

32 haehaea 

33 } 

34 while (h > 0) { 

35 System.out.println("h=" + h); 

36 ir (n >= 4) 

37 latch = new CountDownLatch(arr.length - h); 
38 for (int 1 = h; i < arr.length; i++) { 

39 // 控制 线程 数量 

40 i (n = A i 

41 pool.execute(new ShellSortTask(i, h, 


latch)); 


42 } else { 


43 ir (arn < arrit =- mi) 4 

44 int tmp = arr[i]; 

45 int j =i-h; 

46 while (j >= 0 && arr[j] > tmp) { 
47 ENG leet th rr 

48 J == in; 

49 } 

50 arr[j + h] = tmp; 

51 Í 

52 // System.out.println(Arrays.toString(arr)); 
53 t 

54 } 

55 // 等 待 线程 排序 完成 ， 进 入 下 一 次 排序 

56 latch.await(); 

57 // 计算 出 下 一 个 h 值 

58 h=(h- 1)/3; 

59 } 

60 } 


上 述 代码 中 定义 ShellSortTask 作 为 并 行 任务 。 一 个 ShellSortTask 的 
作用 是 根据 给 定 的 起 始 位 置 和 h， 对 子 数 组 进行 排序 ， 因 此 可 以 完全 并 
行 化 。 


为 控制 线程 数量 ， 这 里 定义 并 行 主 函 数 pShellSort0 在 h 大 于 或 等 于 
4 时 使 用 并 行 线程 (第 40 行 ) ， 否 则 则 退化 为 传统 的 插入 排序 。 


每 次 计算 后 ， 递 减 h 的 值 (第 58 行 ) ° 


5.9 并行 算 法 : FIRE 


我 在 第 一 章 中 已 经 提 到 ，Linus 认 为 并 行程 序 目 前 只 有 在 服务 端 程 
序 和 图 像 处 理 领 域 有 发 展 的 空间 。 且 不 论 这 种 说 法 是 否 正确 ， 但 从 中 
也 可 以 看 出 并 发 对 于 这 两 个 应 用 领域 的 重要 性 。 而 对 于 图 像 处 理 来 
说 ， 和 矩阵 运行 是 其 中 必 不 可 少 的 重要 数学 方法 。 当 然 ， 除 了 图 像 处 
理 ， 和 抢 阵 运算 在 神经 网 络 、 模 式 识 别 等 领域 也 有 着 广泛 的 用 途 。 在 这 
里 ,我 将 癌 大 家 介绍 矩阵 运算 的 典型 代表 一 一 矩阵 乘法 的 并 行 化 实 
现 。 


在 矩阵 乘法 中 ， 第 一 个 矩阵 的 列 数 和 第 二 个 矩阵 的 行 数 必须 是 相 
同 的 。 如 图 5.16 所 示 ， 和 矩阵 A 和 和 矩阵 B 相 乘 ， 其 中 矩阵 A 为 4 行 2 列 ， 撼 
阵 B 为 2 行 4 列 ， 它 们 相 乘 后 ， 得 到 的 是 4 行 4 列 的 矩阵 ， 并 且 新 矩阵 中 
每 一 个 元 素 为 矩阵 A 和 B 对 应 行列 的 乘积 求 和 。 


图 5.16 ”矩阵 相 乘 示意 图 


如 果 需 要 进行 并 行 计算 ， 一 种 简单 的 策略 是 可 以 将 A 矩阵 进行 水 
平分 割 ， 得 到 子 矩 阵 A1 和 A2，B 和 矩阵 进行 垂直 分 割 ， 得 到 和子 和 矩阵 B1 和 
B2。 此 时 ， 我 们 只 要 分 别 计 算 这 些 子 矩 阵 的 乘积 ， 将 结果 进行 拼接 ， 
就 能 得 到 原始 矩阵 A 和 B 的 乘积 。 如 图 5.17 所 示 ， 展 示 了 这 种 并 行 计 算 


的 策略 。 
pe | 


人 :xp 


Ax 
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图 5.17 ”矩阵 拆 分 进行 并 行 计算 


当然 ， 这 个 过 程 是 可 以 反复 进行 的 。 为 了 计算 Al*B1， 我 们 还 可 
以 进一步 将 A1 和 B1 进 行 分 解 ， 直 到 我 们 认为 子 矩 阵 的 大 小 已 经 在 可 接 


这 里 ， 我 们 使 用 ForkJoin 框 架 来 实现 这 个 并 行 和 矩阵 相 乘 的 想法 。 
为 了 方便 矩阵 计算 ， 我 们 使 用 jMatrices 开 源 软件 ， 作 为 矩阵 计算 的 工 
具 。 其 中 ， 使 用 的 主要 API 如 下 : 


e Matrix: 代表 一 个 矩阵 

e MatrixOperator.multiply(Matrix, Matrix): 矩阵 相 乘 
e Matrix.row(): 获得 矩阵 的 行 数 

e Matrix.getSubMatrix(): 获得 矩阵 的 子 矩 阵 


e MatrixOperator.horizontalConcatenation(Matrix,Matrix) : 将 两 个 
矩阵 进行 水 平 连接 
e MatrixOperator.verticalConcatenation(Matrix,Matrix): 将 两 个 矩 


阵 进行 垩 直 连 接 


为 了 计算 矩阵 乘法 ， 定 义 一 个 任务 类 MatrixMulTask。 它 会 进行 汗 
阵 相 乘 的 计算 ， 如 果 输 入 矩阵 的 粒度 比较 大 ， 则 会 再 次 进行 任务 分 
解 : 


01 public class MatrixMulTask extends RecursiveTask<Matrix> { 


02 Matrix m1; 

03 Matrix m2; 

04 String pos; 

05 

06 public MatrixMulTask(Matrix mi, Matrix m2, String pos) { 
07 this.mi = m1; 

08 this.m2 = m2; 

09 this.pos = pos; 

10 } 

11 

12 @Override 

13 protected Matrix compute() { 
14 


//System.out.printin(Thread.currentThread().getId()+":"+Thread. 
currentThread(). 
getName() + " is start"); 


15 if (mi.rows() <= PMatrixMul.granularity | 


m2. 


16 
17 
18 
19 
20 
21 
22 
23 


mi. 


24 


mi. 


25 
26 


m2. 


29 


cols() <= PMatrixMul.granularity) { 


Matrix mRe = MatrixOperator.multiply(m1, m2); 
return mRe; 
} else { 
// 如 果 不 是 ， 那 么 继续 分 割 矩 阵 
int rows; 
rows = mi.rows(); 
// Fe Ren Ra Rs IA] S] 
Matrix mii = mi.getSubMatrix(1, 1, rows / 2, 
cols()); 
Matrix m12 = mi.getSubMatrix(rows / 2 + 1, 1, 
rows(), mi.cols()); 


// 右 乘 矩阵 纵向 分 割 
Matrix m21 = m2.getSubMatrix(1, 


CONS (ky 2 


1, m2.rows(), 


Matrix m22 = m2.getSubMatrix(1, m2.cols() / 2 + 


m2.rows(), m2.cols()); 


ArrayList <MatrixMulTask> subTasks 


ArrayList <MatrixMulTask>(); 


30 
31 
32 
33 
34 
35 
36 


MatrixMulTask tmp = null; 

tmp = new MatrixMulTask(m1i1, m21, 
subTasks.add(tmp); 

tmp = new MatrixMulTask(m11, m22, 
subTasks.add(tmp); 

tmp = new MatrixMulTask(m12, m21, 
subTasks.add(tmp); 


"m1" ) > 


"m2" ) r 


"m3" ) > 


New 


37 tmp = new MatrixMulTask(mi2, m22, "m4"); 


38 subTasks.add(tmp); 

39 for (MatrixMulTask t : subTasks) { 

40 t.fork(); 

41 } 

42 Map<String, Matrix> matrixMap = new HashMap< 


String, Matrix>(); 


43 for (MatrixMulTask t : subTasks) { 

44 matrixMap.put(t.pos, t.join()); 

45 } 

46 Matrix tmp1 = 


MatrixOperator.horizontalConcatenation(matrixMap.get("m1i"), 
matrixMap.get("m2")); 

47 Matrix tmp2 = 
MatrixOperator.horizontalConcatenation(matrixMap.get("m3"), 
matrixMap.get("m4")); 

48 Matrix reM = 
MatrixOperator.verticalConcatenation(tmp1, tmp2); 

49 return reM; 


50 } 


MatrixMulTask 类 由 三 个 参数 构成 ， 分 别 是 需要 计算 的 矩阵 双方 ， 
以 及 计算 结果 位 于 父 和 矩阵 相 乘 结果 中 的 位 置 ， 如 图 5.18 所 示 。 


< 


图 5.18 ”和 矩阵 分 解 方式 


MatrixMulTask 中 的 成 员 变 量 m1 和 m2 表示 要 相 乘 的 两 个 矩阵 ，pos 
表示 这 个 乘积 结果 在 父 矩阵 相 乘 结果 中 所 处 的 位 置 ， 有 m1l、m2、m3 
和 m4 等 四 种 。 代 码 第 23 一 27 行 先 对 矩阵 进行 分 割 ， 分 制 后 得 到 m11、 
m12、m21 和 m22 等 四 个 矩阵 ， 并 将 它们 按照 如 图 5.18 所 示 的 规则 进行 
子 任务 的 创建 。 在 第 39~41 行 ， 计 算 这 些 子 任务 。 在 子 任务 返回 后 ， 
在 第 42~48 行 将 返回 的 四 个 矩阵 m1、m2、m3 和 m4 拼 接 成 新 的 矩阵 作 
为 最 终结 果 。 


如 采 和 矩阵 的 粒度 足够 小 就 直接 进行 运算 而 不 进行 分 解 (第 16 


使 用 这 个 任务 类 可 以 很 容易 地 进行 矩阵 并 行 运算 ， 下 面 是 使 用 方 
法 : 
01 public static final int granularity=3; 


02 public static void main(String[] args) throws 


InterruptedException, ExecutionException 


03 ForkJoinPool forkJoinPool = new ForkJoinPool(); 

04 Matrix mi=MatrixFactory.getRandomIntMatrix(300, 300, 
null); 

05 Matrix m2=MatrixFactory.getRandomIntMatrix(300, 300, 
null); 

06 MatrixMulTask task=new MatrixMulTask(m1,m2,null); 

07 ForkJoinTask < Matrix > result = 


forkJoinPool.submit(task); 


08 Matrix pr=result.get(); 
09 System.out.println(pr); 
10 } 
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任务 MatrixMulTask 并 将 其 提交 给 ForkJoinPool 线 程 池 。 和 第 8 行 执行 
ForkJoinTask.get(0 方 法 等 竺 并 获得 最 终结 果 © 


5.10 ”准备 好 了 再 通知 我 : 网 络 
NIO 


Java NIO 是 New IO 的 简称 ， 它 是 一 种 可 以 奉 代 Java IO 的 一 套 新 的 
IO 机 制 。 它 提供 了 一 套 不 同 于 Java 标 准 IO 的 操作 机 制 。 严 格 来 说 ， 
NIO 与 并 发 并 无 直接 的 关系。 但 是 ， 使 用 NIO 技 术 可 以 大 大 提高 线程 
的 使 用 效率 。 


Java NIO 中 涉及 的 基础 内 容 有 通道 (Channel) 和 缓冲 区 
(Buffer) 、 文 件 IO 和 网 络 IO。 有 关 通 道 、 绥 冲 区 以 及 文件 IO 在 这 里 
不 打算 进行 详细 的 介绍 ， 大 家 可 以 参考 本 章 的 参考 文献 。 在 这 里 ， 我 

想 多 人 花 一 点 时 间 详 细 介 绍 一 下 有 关 了 网 络 IO 的 内 容 。 


对 于 标准 的 网 络 IO 来 说 ， 我 们 会 使 用 Socket 进 行 网 络 的 读 写 。 为 
了 让 服务 器 可 以 支持 更 多 的 客户 端 连接 ， 通 肖 的 做 法 是 为 每 一 个 客户 
端 连 接 开 局 一 个 线程 。 让 我 们 先 回顾 一 下 这 方面 的 内 容 。 


5.10.1 ”基于 Socket 的 服务 端的 多 线程 
模式 


这 里 ， 我 以 一 个 简单 的 Echo 服务 器 为 例 。 对 于 Echo 服务 器 ， 它 会 
读 取 客户 端的 一 个 输入 ， 并 将 这 个 输入 原封 不 动 地 返回 给 客户 端 。 这 
看 起 来 很 简单 ， 但 是 麻 禾 虽 小 五 脏 俱全 。 为 了 完成 这 个 功能 ， 服 务 器 
还 是 需要 有 一 套 完整 的 Socket 处 理 机 制 。 因 此 ， 这 个 Echo 服务 器 非常 


适合 来 进行 和 学习。 实际 上 ， 我 认为 任何 业务 逻辑 位 单 的 系统 都 很 适合 
学 习 ， 大 家 不 用 为 了 去 理解 业务 上 复 洒 的 功能 而 忽略 了 系统 的 重点 。 


服务 端 使 用 多 线程 进行 处 理 时 的 结构 示意 图 ， 如 图 5.19 所 示 。 
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图 5.19 ”多 线程 的 服务 端 


服务 套 会 为 每 一 个 客户 器 连接 局 用 一 个 线程 ， 这 个 新 的 线程 将 全 
心 全 意 为 这 个 客户 只 服务 。 同 时 ， IRA rsh 
额外 使 用 一 个 派发 线程 。 


下 面 的 代码 实现 了 这 个 服务 器 : 


01 public class MultiThreadEchoServer { 
02 private static ExecutorService 


tp=Executors.newCachedThreadPool(); 


03 static class HandleMsg implements Runnable{ 
04 Socket clientSocket; 

05 public HandleMsg(Socket clientSocket){ 
06 this.clientSocket=clientSocket; 


07 } 


08 


09 public void run(){ 

10 BufferedReader is =null; 

11 PrintWriter os = null; 

12 try { 

13 

14 is = new BufferedReader (new 


InputStreamReader (clientSocket.getInputStream())); 
15 os = new 


PrintWriter(clientSocket.getOutputStream(), true); 


16 // 从 InputStream 当 中 读 取 客户 端 所 发 送 的 数据 
17 String inputLine = null; 

18 long b=System.currentTimeMillis(); 

19 while ((inputLine = is.readLine()) != null) 
{ 

20 os.printin(inputLine); 

21 } 

22 long e=System.currentTimeMillis(); 

23 System.out.println("spend:"+(e-b)+"ms"); 
24 } catch (IOException e) { 

25 e.printStackTrace(); 

26 }finally{ 

27 try { 

28 if(is!=null)is.close(); 

29 if(os!=null)os.close(); 

30 clientSocket.close(); 


31 } catch (IOException e) { 


32 e.printStackTrace(); 


33 } 

34 } 

35 } 

36 } 

37 public static void main(String args[]) { 

38 ServerSocket echoServer = null; 

39 Socket clientSocket = null; 

40 try { 

41 echoServer = new ServerSocket(8000) ; 
42 } catch (IOException e) { 

43 System.out.printin(e); 

44 } 

45 while (true) { 

46 try { 

47 clientSocket = echoServer.accept(); 
48 


System.out.println(clientSocket.getRemoteSocketAddress() + " 


connect!"); 


49 tp.execute(new HandleMsg(clientSocket) ); 
50 } catch (IOException e) { 

51 System.out.printlin(e); 

52 } 

53 } 

54 } 


第 2 行 ， 我 们 使 用 了 一 个 线程 池 来 处 理 每 一 个 客户 端 连 接 。 人 第 3 一 
33 行 ， 定 义 了 HandleMsg 线 程 ， 它 由 一 个 客户 端 Socket 构 造 而 成 ， 它 的 
任务 是 读 取 这 个 Socket 的 内 容 并 将 其 进行 返回 ， 返 回 成 功 后 ， 任 务 完 
成 ， 客 户 端 Soceket 歌 被 正常 关闭 。 其 中 第 23 行 ， 统 计 并 输出 了 服务 端 
线程 处 理 一 次 客户 端 请 求 所 花费 的 时 间 〈 包 括 读 取 数 据 和 回 写 数据 的 
时 间 ) 。 主 线程 main 的 主要 作用 是 在 8000 端 口上 进行 等 待 。 一 旦 有 新 
的 客户 端 连接 ， 它 就 根据 这 个 连接 创建 HandleMsg 线 程 进 行 处 理 (第 
47~-49 行 ) ° 


这 束 是 一 个 文 持 多 线程 的 服务 端的 核心 内 容 。 它 的 特点 是 ， 在 相 
同 可 文 持 的 线程 范围 内 ， 可 以 尽量 多 地 文 持 客户 端的 数量 ， 同 时 和 单 
线程 服务 器 相 比 ， 它 也 可 以 更 好 地 使 用 多 核 CPU 。 


为 了 方便 大 家 学 习 ， 这 里 再 给 出 一 个 客户 端的 参考 实现 : 


01 public static void main(String[] args) throws IOException { 


02 Socket client = null; 

03 PrintWriter writer = null; 

04 BufferedReader reader = null; 

05 try { 

06 client = new Socket(); 

07 client.connect(new InetSocketAddress("localhost", 
8000) ); 

08 writer = new PrintWriter(client.getOutputStream(), 
true); 

09 writer.println("Hello!"); 

10 writer.flush(); 


11 


12 


reader = new BufferedReader (new 


InputStreamReader(client.getInputStream())); 


13 System.out.printin("from server: " + 
reader.readLine()); 
14 } catch (UnknownHostException e) { 
15 e.printStackTrace(); 
16 } catch (IOException e) { 
17 e.printStackTrace(); 
18 } finally { 
19 if (writer != null) 
20 writer.close(); 
21 if (reader != null) 
22 reader.close(); 
23 if (client != null) 
24 client.close(); 
25 } 
26 } 
上 述 代码 在 第 7 行 ， 连 接 了 服务 器 的 8000 端 口 ， 并 发 送 字 符 串 。 接 


着 在 第 12 行 ， 读 取 服 务 絮 的 返回 信息 并 进行 输出 。 


可 以 说 ,这 种 多 线程 的 服务 右 开 发 模式 古 极 其 常用 的 。 对 于 绝 大 
多 数 应 用 来 说 ， 这 种 模式 可 以 很 好 地 工作 。 但 是 ， 如 果 你 想 让 你 的 程 
序 工作 得 更 加 有 效 ， 束 必须 知道 这 种 模式 的 一 个 重大 弱点 一 一 那 束 是 
它 倾 向 于 让 CPU 进行 IO 等 待 。 为 了 理解 这 一 点 ， 让 我 们 看 一 下 下 面 这 


个 比较 极端 的 例子 : 


01 public class HeavySocketClient { 


02 


private static ExecutorService 


tp=Executors.newCachedThreadPool(); 


03 
04 
05 
06 
07 
08 
09 
10 
Het 


private static final int sleep_time=1000*1000*1000; 
public static class EchoClient implements Runnable{ 
public void run(){ 

Socket client = null; 

PrintWriter writer = null; 

BufferedReader reader = null; 

try { 

client = new Socket(); 


client.connect (new 


InetSocketAddress("localhost", 8000)); 


12 


writer = new 


PrintWriter(client.getOutputStream(), true); 


13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 


writer.print("H"); 
LockSupport.parkNanos(sleep_time); 
writer.print("e"); 
LockSupport.parkNanos(sleep_time) ; 
writer.print("1"); 
LockSupport.parkNanos(sleep_time) ; 
writer.print("1"); 
LockSupport.parkNanos(sleep_time) ; 
writer.print("o"); 
LockSupport.parkNanos(sleep_time) ; 
writer.print("!"); 


LockSupport.parkNanos(sleep_time) ; 


25 writer.printJln()， 


26 writer.flush(); 
27 
28 reader = new BufferedReader (new 


InputStreamReader(client.getInputStream())); 


29 System.out.printin("from server: " + 


reader.readLine()); 


30 } catch (UnknownHostException e) { 
31 e.printStackTrace(); 

32 } catch (IOException e) { 

33 e.printStackTrace(); 

34 } finally { 

35 try { 

36 if (writer != null) 

37 writer.close(); 

38 if (reader != null) 

39 reader .close(); 

40 if (client != null) 

41 client.close(); 

42 } catch (IOException e) { 

43 } 

44 } 

45 } 

46 } 

47 public static void main(String[] args) 


IOException { 


48 EchoClient ec=new EchoClient(); 


throws 


49 for(int i=0;i<10;i++) 


50 tp.execute(ec); 


上 述 代 码 定义 了 一 个 新 的 客户 端 ， 它 会 进行 10 次 请 求 (4950 
行 开 启 10 个 线程 ) 。 每 一 次 请 求 都 会 访问 8000 端 口 。 连 接 成 功 后 ， 会 
向 服务 器 输出 “Hello!” 字 符 串 (8132647) ， 但 是 在 这 一 次 交互 中 ， 
客户 端 会 慢 慢 地 进行 输出 ， 每 次 只 输出 一 个 字符 ， 之 后 进行 1 秒 的 等 
待 。 因 此 ， 整 个 过 程 会 持续 6 秒 。 


开局 多 线程 池 的 服务 种 和 上 述 客户 端 。 服 务 串 端的 部 分 输出 如 
T 


spend :6000ms 
spend: 6000ms 
spend: 6000ms 
spend: 6001ms 
spend: 6002ms 
spend: 6002ms 
spend: 6002ms 
spend: 6002ms 
spend: 6003ms 
spend: 6003ms 
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右 。 这 很 容易 理解 ， 因 为 服务 器 要 先 读 入 客户 端的 输入 ， 而 客户 端 绥 


慢 的 处 理 速度 (当然 也 可 能 是 一 个 拥塞 的 网 络 环境 ) 使 得 服务 器 花费 
了 不 少 等 待 时 间 。 


我 们 可 以 试想 一 人 下， 如 采 服 务 右 要 处 理 大 量 的 请 求 连 接 ， 每 个 请 
求 如 果 都 像 这 样 拖 慢 了 服务 器 的 处 理 速度 ， 那 么 服务 端 能 够 处 理 的 并 
发 数量 欧 会 大 幅度 减少 。 反 之 ， 如 采 服 务 硕 每 次 都 能 很 快 地 处 理 一 次 
请 求 ， 那 么 相对 的 ， 它 的 并 发 能 力 丈 能 上 升 。 

在 这 个 案例 中 ， 服 务 右 处理 请 求 之 所 以 慢 ， 并 不 是 因为 在 服务 端 
有 多 少 和 党 重 的 任务 ， 而 仅仅 是 因为 服务 线程 在 等 竺 IO 而 已 。 让 高 速 运 
转 的 CPU 去 等 待 极其 低 效 的 网 络 IO 是 非常 不 合算 的 行为 那么 ， 我 们 
是 不 是 可 以 想 一 个 方法 ， 将 网 络 IO 的 等 待 时 间 从 线程 中 分 离 出 来 呢 ? 


5.10.2 ”使 用 NIO 进 行 网 络 编程 


使 用 Java 的 NIO 束 可 以 将 上 面 的 网 络 IO 等 每 时 间 从 业务 处 理 线程 
中 抽取 出 来 。 那 么 NIO 是 什么 ， 它 又 是 如 何 工作 的 呢 ? 


要 了 解 NIO， 我 们 首先 需要 知道 在 NIO 中 的 一 个 关键 组 件 Channel 

(通道 ) 。Channel 有 点 类 似 于 流 ， 一 个 Channel 可 以 和 文件 或 者 网 络 

Socket 对 应 。 如 果 Channel 对 应 着 一 个 Soceket， 那 么 往 这 个 Channel 中 
写 数据 ， 束 等 同 于 问 Socket 中 写 入 数据 。 


和 Channel 一 起 使 用 的 另外 一 个 重要 组 件 就 是 Buffer。 大 家 可 以 简 
单 地 把 Buffer 理 解 成 一 个 内 存 区 域 或 者 byte 数 组 。 数 据 需 要 包装 成 
Buffer 的 形式 才能 和 Channel 交 互 ( 写 入 或 者 读 取 ) 。 


另外 一 个 与 Channel 密 切 相 关 的 是 Selector (选择 器 ) 。 在 Channel 
的 众多 实现 中 ， 有 一 个 SelectableChannel 实 现 ， 表 示 可 被 选择 的 通道 。 
任何 一 个 SelectableChannel 都 可 以 将 目 己 注册 到 一 个 Selector 中 。 这 
样 ， 这 个 Channel 就 能 被 Selector 所 管理 。 而 一 个 Selector 可 以 管理 多 个 
SelectableChannel。 当 SelectableChannel 的 数据 准备 好 时 ，Selector 就 会 
接 到 通知 ， 得 到 那些 已 经 准备 好 的 数据 。 而 SocketChannel 就 是 
SelectableChannel 的 一 种 。 因 此 ， 它 们 构成 了 如 图 5.20 所 示 的 结构 。 
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图 5.20 ”Selector 和 Channel 


大 家 可 以 看 到 ， 一 个 Selector 可 以 由 一 个 线程 进行 管理 ， 而 一 个 
SocketChannel 则 可 以 表示 一 个 客户 问 连 授 ， 因 此 这 惑 构 成 由 一 个 或 者 
极 少 数 线程 ， 来 处 理 大 量 客户 端 连 接 的 结构 。 当 与 客户 端 连 接 的 数据 
没有 准备 好 时 ，Selector 会 处 于 等 待 状态 (ASH, ATE 
Selector 的 线程 数 是 极 少量 的 ， 而 一 旦 有 任何 一 个 SocketChannel 准 备 
好 了 数据 ，Selector 束 能 立即 得 到 通知 ， 获 取 数 据 进行 处 理 。 


下 面 就 让 我 们 用 NIO 来 重新 构造 这 个 多 线程 的 Echo 服 务 絮 吧 ! 
首先 ， 我 们 需要 定义 一 个 Selector 和 线程 池 : 


private Selector selector; 


private ExecutorService tp=Executors.newCachedThreadPool(); 


其 中 ，selector 用 于 处 理 所 有 的 网 络 连 接 。 线 程 池 tp 用 于 对 每 一 个 
客户 端 进 行 相应 的 处 理 ， 每 一 个 请 求 都 会 委托 给 线程 池 中 的 线程 进行 
实际 的 处 理 。 

为 了 能 够 统计 服务 器 线程 在 一 个 客户 端 上 花费 了 多 少时 间 ， 这 里 
还 需要 定义 一 个 与 时 间 统 计 有 关 的 类 : 
public static Map < Socket, Long> time_stat=new HashMap < 


Socket, Long> (10240); 


它 用 于 统计 在 某 一 个 Socket 上 花费 的 时 间 ，time_stat 的 key 为 
Socket，value 为 时 间 惟 〈 可 以 记录 处 理 开 始 时 间 ) 。 


下 面 束 可 以 来 看 一 人 NIO 服 务 需 的 核心 代码 ， 下 面 的 startServer() 
方法 用 于 启动 NIO Server: 


01 private void startServer() throws Exception { 


02 selector = SelectorProvider.provider().openSelector(); 

03 ServerSocketChannel ssc = ServerSocketChannel.open(); 

04 ssc.configureBlocking(false) ; 

05 

06 InetSocketAddress isa = new 


InetSocketAddress(InetAddress.getLocalHost(), 8000); 
07 InetSocketAddress isa = new InetSocketAddress(8000); 
08 ssc.socket().bind(isa); 


09 


10 SelectionkKey acceptKey = ssc.register(selector, 


SelectionKkKey .OP_ACCEPT ) ; 


11 

12 COR Gy ot 

13 selector.select(); 

14 Set readyKeys = selector .selectedKeys(); 

LS Iterator i = readyKeys.iterator(); 

16 long e=0; 

17 while (i.hasNext()) { 

18 SelectionKey sk = (SelectionKey) i.next(); 
19 i.remove(); 

20 

21 if (sk.isAcceptable()) { 

22 doAccept(sk); 

23 } 

24 else if (sk.isValid() && sk.isReadable()) { 
25 


if(!time_stat.containsKey(((SocketChannel)sk.channel()).socket( 
))) 
26 


time_stat.put(((SocketChannel)sk.channel()).socket(), 


27 System.currentTimeMillis()); 

28 doRead(sk); 

29 } 

30 else if (sk.isValid() && sk.isWritable()) { 
31 dowWrite(sk); 


32 e=System.currentTimeMillis(); 


33 long 
b=time_stat.remove(((SocketChannel)sk.channel()).socket()); 


34 System.out.printin("spend:"+(e-b)+"ms"); 


上 述 代 码 第 2 行 ， 通 过 工厂 方法 获得 一 个 Selector 对 和 象 的 实例 。 第 3 
行 ， 获 得 表示 服务 端的 SocketChannel 实 例 。 第 4 行 ， 将 这 个 
SocketChannel 设 置 为 非 阻塞 模式 。 实 际 上 ，Channel 也 可 以 像 传统 的 
Socket 那 样 按照 阻塞 的 方式 工作 。 但 在 这 里 ， 更 倾向 于 让 其 工作 在 非 
阻塞 模式 ， 在 这 种 模式 下 ， 我 们 才 可 以 向 Channel 注 册 感 兴趣 的 事件 ， 
并 且 在 数据 准备 好 时 ， 得 到 必要 的 通知 。 接 着 ， 在 第 6 一 8 行进 行 端口 
绑 定 ， 将 这 个 Channel 绑 定 在 8000 端 口 。 


在 第 10 行 ， 将 这 个 ServerSocketChannel 绑 定 到 Selector 上 ， 并 注册 
它 感 兴趣 的 时 间 为 Accept。 这 样 ，Selector 就 能 为 这 个 Channel 服 务 了 。 
当 Selector 发 现 ServerSocketChannelj 有 新 的 客户 端 连接 时 ， 束 会 通知 
ServerSocketChannel 进行 处 理 。 方 法 register0 的 返回 值 是 一 个 
SelectionKey ， SelectionKey 表 示 一 对 Selector 和 Channel 的 关系 。 当 
Channel 注 册 到 Selector 上 时 ， 就 相当 于 确立 了 两 者 的 服务 天 系 ， 那 么 
SelectionKey 束 是 这 个 兆 约 。 当 Selector 或 者 Channel 被 关闭 上 时， 它们 对 
应 的 SelectionKey 就 会 失效 。 


第 12~37 行 是 一 个 无 穷 循 环 ， 它 的 主要 任务 承 是 等 行 -分 发 网 络 请 
Eo 


第 13 行 的 select(0) 方 法 是 一 个 阻塞 方法 。 如 果 当 前 没有 任何 数据 准 
备 好 ， 它 束 会 等 待 。 一 旦 有 数据 可 读 ， 它 融会 返回 。 它 的 返回 值 是 已 
经 准备 束 绪 的 SelectionKey 的 数量 。 这 里 简单 地 将 其 忽略 。 


第 14 行 获取 那些 准备 好 的 SelectionKey。 因 为 Selector 同 时 为 多 个 
Channel 服 务 ， 因 此 已 经 准备 就 绪 的 Channel 就 有 可 能 是 多 个 。 所 以 ， 
这 里 得 到 的 上 自然 是 一 个 集合 。 得 到 这 个 束 绪 集合 后 ， 剩 下 的 就 是 损 历 
这 个 集合 ， 挨 个 处 理 所 有 的 Channel 数 据 。 


第 15 行 得 到 这 个 集合 的 迭代 右 。 第 17 行 使 用 迭代 颖 遍历 整个 集 
合 。 第 18 行 根据 迭代 恬 获 得 一 个 集合 内 的 SelectionKey 实 例 。 

第 19 行 将 这 个 元 素 移 除 ! 注意 ， 这 个 非常 重要 ， 否 则 就 会 重复 处 
理 相 同 的 SelectionKey。 当 你 处 理 完 一 个 SelectionKey 后 ， 务 必 将 其 从 
集合 内 删除 。 


第 21 行 判断 当前 SelectionKey 所 代表 的 Channel 是 否 在 Acceptable 状 
人 态 ， 如 果 是 ， 束 进行 客户 端的 接收 〈 执 行 doAccept() 方 法 ) 


第 24 行 判断 Channel 是 否 已 经 可 以 读 了 ， 如 果 是 吏 进 行 读 取 
(doRead() 方 法 ) 。 这 里 为 了 统计 系统 处 理 每 一 个 连接 的 时 间 ， 在 第 
25~~27 行 记录 了 在 读 取 数据 之 前 的 一 个 时 间 鹤 。 


第 30 行 判断 通道 是 否 准备 好 进行 号 。 如 果 是 驶 进行 写 入 
(doWrite() 方 法 ， 同 时 在 写 入 完成 后 ， 根 据 读 取 前 的 时 间 戳 ， 输 出 
处 理 这 个 Socket 连 接 的 耗 时 。 


在 了 解 服务 端的 整体 框架 后 ， 下 面 让 我 们 从 细节 着 手 ， 学 习 一 下 
几 个 主要 方法 的 内 部 实现 。 首 先是 doAccept0 方 法 ， 它 与 客户 端 建立 连 


01 private void doAccept(SelectionKey sk) { 
02 ServerSocketChannel server = (ServerSocketChannel ) 


sk.channel(); 


03 SocketChannel clientChannel; 

04 try { 

05 clientChannel = server.accept(); 

06 clientChannel.configureBlocking(false); 

07 

08 // Register this channel for reading. 

09 Selectionkey clientKey = 


clientChannel.register(selector, SelectionKey.OP_READ) ; 
10 // Allocate an EchoClient instance and attach it to 


this selection key. 


11 EchoClient echoClient = new EchoClient(); 

12 clientKey.attach(echoClient ); 

13 

14 InetAddress clientAddress = 


clientChannel.socket().getInetAddress(); 
15 System.out.println("Accepted connection from " + 


clientAddress.getHostAddress() + "."); 


16 } catch (Exception e) { 

17 System.out.printin("Failed to accept new client."); 
18 e.printStackTrace(); 

19 } 


和 Socket 编 程 很 类 似 ， 当 有 一 个 新 的 客户 端 连 接 接 入 时 ， 就 会 有 
一 个 新 的 Channel 产 生 代 表 这 个 连 授 。 上 述 代 码 第 5 行 ， 生 成 的 
clientChannel 束 表示 和 客户 端 通信 的 通道 。 第 6 行 ， 将 这 个 Channel 配 置 
为 非 阻塞 模式 ， 也 就 是 要 求 系统 在 准备 好 IO 后 ， 再 通知 我 们 的 线程 来 
读 取 或 者 写 入 。 


第 9 行 很 关键 ， 它 将 新 生成 的 Channel 注 册 到 a wE, # 
告诉 Selector ， 我 现在 对 读 (OP_READ) 操作 感 兴 Aia oS 
Selector 发 现 这 个 Channel 已 经 准备 好 读 时 ， 残 能 通知 。 


第 11 行 狐 建 一 个 对 象 实 例 ， 一 个 EchoClient 实 例 代 表 一 个 客户 端 。 
在 第 12 行 ， AUE TE 内 实例 作为 附件 ， 附 加 到 表示 这 个 连接 的 
SelectionKey 上 “。 这 样 在 整个 连接 的 处 理 过 程 中 ， 我 们 都 可 以 共享 这 个 
EchoClient 实 例 。 


EchoClient 的 定义 很 简单 ， 它 封装 了 一 个 队列 ， 保 存在 需要 回复 给 
个 客户 端的 所 有 人 信息， 这样 ， 再 进行 回复 时 ， 只 要 从 outq 对 象 中 弹 
o 


class EchoClient { 
private LinkedList<ByteBuffer> outq; 
EchoClient() { 
outq = new LinkedList<ByteBuffer>(); 
i 
public LinkedList<ByteBuffer> getOutputQueue() { 
return outq; 


} 
public void enqueue(ByteBuffer bb) { 


outq.addFirst(bb); 


下 面 来 看 一 下 另外 一 个 重要 的 方法 doRead0。 当 Channel 可 以 读 取 


H 上 时 ，doRead0) 方 法 就 会 被 调用 。 


01 private void doRead(Selectionkey sk) { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 


SocketChannel channel = (SocketChannel) sk.channel(); 
ByteBuffer bb = ByteBuffer.allocate(8192); 


int len; 


try { 


len = channel.read(bb); 
if (len < 0) { 
disconnect(sk); 
return; 
} 
} catch (Exception e) { 
System.out.println("Failed to read from client."); 
e.printStackTrace(); 
disconnect(sk); 


return; 


bb.flip(); 


20 tp.execute(new HandleMsg(sk,bb)); 
21 } 


方法 doRead() 接 收 一 个 SelectionKey 参 数 ， 通 过 这 个 SelectionKey 可 
以 得 到 当前 的 客户 端 Channel (第 2 行 ) 。 在 这 里 ， 我 们 准备 8K 的 绥 促 
区 读 取 数据 ， 所 有 读 取 的 数据 存放 在 变量 bb 中 〈 第 7 行 ) 。 读 取 完 成 
后 ， 重 置 缓冲 区 ， 为 数据 处 理 做 准备 (第 19 行 ) 。 


在 这 个 示例 中 ， 我 们 对 数据 的 处 理 很 消 单 。 但 是 为 了 模拟 复杂 的 
场景 ， 还 是 使 用 了 线程 池 进 行 数据 处 理 〈 第 20 行 ) 。 这 样 ， 如 果 数 据 
处 理 很 复杂 ， 残 能 在 单独 的 线程 中 进行 ， 而 不 用 阻塞 任务 派发 线程 。 


HandleMsg 的 实现 也 很 简单 : 


01 class HandleMsg implements Runnable{ 


02 Selectionkey sk; 

03 ByteBuffer bb; 

04 public HandleMsg(SelectionKey sk,ByteBuffer bb) { 

05 this.sk=sk; 

06 this.bb=bb; 

07 } 

08 @Override 

09 public void run() { 

10 EchoClient echoClient = (EchoClient) 


sk.attachment(); 
11 echoClient.enqueue(bb); 
12 sk.interestOps(SelectionKey.OP_READ | 


SelectionKey.OP_WRITE); 


13 // 强 迫 selector 立 即 返回 


14 selector .wakeup(); 


上 述 代 码 ， 简 单 地 将 接收 到 的 数据 压 入 EchoClient 的 队列 (第 11 
行 ) 。 如 果 需 要 处 理 业务 逻辑 ， 就 可 以 在 这 里 进行 处 理 。 


在 数据 处 理 完 成 后 ， 束 可 以 准备 将 结果 回 写 到 客户 端 ， 因 此 ， 重 
新 注册 感 兴趣 的 消息 事件 ， 将 写 操 作 (OP_WRITE) 也 作为 感 兴趣 的 
事件 进行 提交 (第 12 行 ) 。 这 样 在 通道 准备 好 写 入 时 ， 就 能 通知 线 
程 。 


写 入 操作 使 用 doWrite0 函 数 实现 ; 


01 private void dowrite(Selectionkey sk) { 


02 SocketChannel channel = (SocketChannel) sk.channel(); 
03 EchoClient echoClient = (EchoClient) sk.attachment(); 
04 LinkedList <ByteBuffer > outd = 


echoclient .getoutputQueue( ) ; 


05 

06 ByteBuffer bb = outq.getLast(); 
07 try { 

08 int len = channel.write(bb); 
09 if (len == -1) 4 

10 disconnect(sk); 

11 return; 


12 4 


14 if (bb.remaining() == 0) { 

15 // The buffer was completely written, remove it. 
16 outq.removeLast(); 

17 } 

18 } catch (Exception e) { 

19 System.out.println("Failed to write to client."); 
20 e.printStackTrace(); 

21 disconnect(sk); 

22 } 

23 

24 if (outq.size() == 0) { 

25 sk.interestOps(SelectionKey.OP_READ) ; 

26 } 

27 } 


函数 doWrite0 也 接收 一 个 SelectionKey， 当 然 针 对 一 个 客户 端 来 
说 ， 这 个 SelectionKey 实 例 和 doRead0 拿 到 的 SelectionKey 是 同一 个 。 
此 ， 通 过 SelectionKey 我 们 就 可 以 在 这 两 个 操作 中 共享 EchoClient 实 
例 。 上 述 代 码 第 3~4 行 ， 我 们 取得 EchoClient 实 例 以 及 它 的 发 送 内 容 列 
表 。 第 6 行 ， 获 得 列表 顶部 元 素 ， 准 备 写 回 客户 端 。 第 8 行进 行 写 回 操 
作 。 如 果 全 部 发 送 完 成 ， 则 移 除 这 个 缓存 对 象 (第 16 行 ) ° 

在 dowWrite0 中 最 重要 的 ， 也 是 最 容易 被 忽略 的 是 在 全 部 数据 发 送 


完成 后 〈 也 就 是 outq 的 长 度 为 0) ， 需 要 将 写 事 件 (OP_WRITE) ME 
兴趣 的 操作 中 移 除 (第 25 行 )。 如 果 不 这 么 做 ， 每 次 Channel 准 备 好 写 


时 ， 都 会 来 执行 doWriteO 方 法 。 而 实际 上 ， 你 又 无 数据 可 写 ， 这 显然 
征 不 合理 的 。 因 此 ， 这 个 操作 很 重要 。 


上 面 我 们 已 经 介绍 了 主要 的 核心 代码 ， 现 在 使 用 这 个 NIO 服 务 天 
来 处 理 上 一 和 中 客户 端的 访问 。 同 样 的， 客户 端 也 是 要 人 花费 将 近 6 秘 
钟 ， 才 能 完成 一 次 请 妃 的 发 送 ， 那 使 用 NIO 技 术 后 ， 服 务 端 线程 需要 
化 费 多 少时 间 来 处 理 这 些 请 求 呢 ? 答案 如 下 : 


spend: 2ms 
spend: 2ms 
spend: 2ms 
spend: 2ms 
spend: 3ms 
spend: 3ms 
spend: Oms 
spend: Oms 
spend: 2ms 


spend: 3ms 
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延迟 等 现象 ， 并 不 会 给 服务 器 市 来 太 大 的 问题 。 


5.10.3 “使 用 NIO 来 实现 客户 端 


在 前 面 的 案例 中 ， 我 们 使 用 Socket 编 程 来 构建 我 们 的 客户 端 ， 
用 NIO 来 实现 服务 端 。 实 际 上 ， 使 用 NIO 也 可 以 用 来 创建 客户 端 。 
里 ， 我 们 再 演示 一 下 使 用 NIO 创 建 客户 端的 例子 。 


54 演 


和 构造 服务 器 类 似 ， 核 心 的 元 素 也 是 Selector `> Channel 和 
SelectionKey ° 


首先 ， 我 们 需要 初始 化 Selector 和 Channel: 


01 private Selector selector; 


02 public void init(String ip, int port) throws IOException { 


03 SocketChannel channel = SocketChannel.open(); 
04 channel.configureBlocking(false); 
05 this.selector = 


SelectorProvider.provider().openSelector(); 


06 channel.connect(new InetSocketAddress(ip, port)); 
07 channel.register(selector, SelectionKey.O0OP_CONNECT); 
08 } 


上 述 代 码 第 3 行 ， 创 建 一 个 SocketChannel 实 例 ， 并 设置 为 非 阳 塞 
模式 。 第 5 行 创 建 了 一 个 Selector。 第 6 行 ， 将 SocketChannel 绑 定 到 
Socket 上 。 但 由 于 当前 Channel 是 非 阻塞 的 ， 因 此 ，connect() 方 法 返回 
时 ， 连 接 并 不 一 定 建 立成 功 ， 在 后 续 使 用 这 个 连接 时 ， 还 需要 使 用 
finishConnectO 再 次 确认 。 第 7 行 ， 将 这 个 Channel 和 Selector 进 行 绑 定 ， 
并 注册 了 感 兴趣 的 事件 作为 连接 (OP_CONNECT) 。 


Meee se Awe, Wie EA AYE RUT eae 


01 public void working() throws IOException { 
02 while (true) { 

03 if (!selector.isOpen()) 

04 break; 


05 selector.select(); 
06 Iterator <SelectionKkey > ite = 


this.selector.selectedKeys().iterator(); 


07 while (ite.hasNext()) { 

08 SelectionKey key = ite.next(); 
09 ite.remove(); 

10 /7 连 拉 事件 发 生 

11 if (key.isConnectable()) { 

12 connect(key); 

L8 } else if (key.isReadable()) { 
14 read(key); 

15 } 

16 } 

17 } 

18 } 


在 上 述 代码 中 ， 第 5 行 通过 Selector 得 到 已 经 准备 好 的 事件 。 如 果 
当前 没有 任何 事件 准备 就 绕 ， 这 里 就 会 月 塞 。 这 里 的 整个 处 理 机 制 和 
服务 端 非常 类 似 ， 主 要 处 理 两 个 事件 ， 首 先是 表示 连接 就 绪 的 Connct 
事件 〈 由 connect0 函 数 处 理 ) 以 及 表示 通道 可 读 的 Read 事 件 (由 read0) 
函数 处 理 ) o 


函数 connect0 的 实现 如 下 : 


01 public void connect(SelectionKkey key) throws IOException { 
02 SocketChannel channel = (SocketChannel) key.channel(); 
03 // 如 采 正 在 连接 ， 则 完成 连接 


04 if (channel.isConnectionPending()) { 


05 channel.finishConnect(); 


06 } 
07 channel.configureBlocking(false); 
08 channel.write(ByteBuffer.wrap(new String("hello 


server!\r\n") 


09 .getBytes())); 
10 channel.register(this.selector, SelectionKey.OP_READ) ; 
Ty 


上 述 connect0 函 数 接收 SelectionKey 作 为 其 参数 。 在 第 4~-6 行 ， 它 
惠 先 判断 是 否 连 接 已 经 建立 ， 如 有 果 没有 ， 则 调用 finishConnectO 完 成 连 
授 。 建 立 连接 后 ， 同 Channel 写 入 数据 ， 并 同时 注册 读 事 件 为 感 兴趣 的 
事件 (第 10 行 ) 。 


当 Channel 可 读 时 ， 会 执行 read0 方 法 ， 进 行 数据 读 取 : 


01 public void read(SelectionKey key) throws IOException { 


02 SocketChannel channel = (SocketChannel) key.channel(); 
03 // 创建 读 取 的 缓冲 区 

04 ByteBuffer buffer = ByteBuffer.allocate(100) ; 

05 channel.read(buffer); 

06 byte[] data = buffer.array(); 

07 String msg = new String(data).trim(); 

08 System.out.printlLn(" 客 户 端 收 到 信息 : " + msg); 

09 channel.close(); 

10 key.selector().close(); 


dee 


上 述 read0 函 数 首 先 创建 了 100 字 节 的 缓冲 区 (第 4 行 ) ， 接 着 从 
Channel 中 读 取 数据 ， 并 将 其 打印 在 控制 台 上 。 最 后 ， 天 闭 Channel 和 


Selector ° 


5.11 wesc TRAIN: AIO 


AIO 是 异步 IO 的 缩写 ， 即 Asynchronized。 虽 然 NIO 在 网 络 探 作 
中 ， 提 供 了 非 阻 塞 的 方法 ， 但 是 NIO 的 IO 行为 还 是 同步 的 。 对 于 NIO 
来 说 ， 我 们 的 业务 线程 是 在 IO 操作 准备 好 时 ， 得 到 通知 ， 接 着 瓯 由 这 
个 线程 自行 进行 IO 操作 ，IO 操 作 本 喘 还 是 同步 的 。 


但 对 于 AIO 来 说 ， 则 更 加 进 了 一 步 ， 它 不 是 在 IO 准备 好 时 再 通知 
线程 ， 而 是 在 IO 操作 已 经 完成 后 ， 再 给 线程 发 出 通知 。 因 此 ，AIO 和 是 
完全 不 会 阻 蹇 的 。 此 时 ， 我 们 的 业务 逻辑 将 变 成 一 个 回调 函数 ， 等 行 
IO 操作 完成 后 ， 由 系统 目 动 触发 。 


下 面 ， 我 将 通过 AIO 来 实现 一 个 简单 的 EchoServer 以 及 对 应 的 客户 
Wirt e 


5.11.1 AIO EchoServer 的 实现 


异步 10 需 要 使 用 异步 通道 (AsynchronousServerSocketChannel) : 


public final static int PORT = 8000; 
private AsynchronousServerSocketChannel server; 
public AIOEchoServer() throws IOException { 
server = AsynchronousServerSocketChannel.open().bind(new 
InetSocketAddress(PORT) ); 
i 


上 述 代 码 绑 定 了 8000 端 口 为 服务 器 端口 ， 并 使 用 
AsynchronousServerSocketChannel #77 Channel /F ARB as, DBA 


server ° 
我 们 使 用 这 个 server 来 进行 客户 端的 接收 和 处 理 : 


01 public void start() throws InterruptedException, 


ExecutionException, TimeoutException { 


02 System.out.println("Server listen on " + PORT); 
03 // 注 册 事 件 和 事件 完成 后 的 处 理 器 
04 server.accept(null, new CompletionHandler < 


AsynchronousSocketChannel, Object>() { 

05 final ByteBuffer buffer = ByteBuffer.allocate(1024); 
06 public void completed(AsynchronousSocketChannel 
result, Object attachment) { 

07 


System.out.printin(Thread.currentThread().getName()); 


08 Future<Integer> writeResult=null; 

09 try { 

10 buffer.clear(); 

11 result.read(buffer).get(100, 


TimeUnit ,SECONDS ) ; 


12 buffer.flip(); 
13 writeResult=result.write(buffer); 
14 } catch (InterruptedException | 


ExecutionException e) { 


15 e.printStackTrace(); 


16 } catch (TimeoutException e) { 


17 e.printStackTrace(); 

18 } finally { 

19 try { 

20 server.accept(null, this); 

21 writeResult.get(); 

22 result.close(); 

23 } catch (Exception e) { 

24 System.out.println(e.toString()); 
25 } 

26 t 

27 } 

28 

29 @Override 

30 public void failed(Throwable exc, Object attachment ) 
{ 

31 System.out.printin("failed: " + exc); 

32 } 

33 }); 

34 } 


上 述 定 义 的 start(0) 方 法 开局 了 服务 右 。 值 得 注意 的 是 ， 这 个 方法 除 
了 第 2 行 的 打印 语句 外 ， rea alee 。 之 后 ， 你 看 
到 的 那 一 大 堆 代 码 只 是 这 个 函数 的 参数 。 


E see o ie ear accept() 方 法 会 立即 返回 。 它 并 
不 会 真 的 去 等 待 客户 端的 到 来 。 在 这 里 使 用 的 accept() 方 法 的 签名 为 : 


public final <A> void accept(A attachment, 
CompletionHandler < 


AsynchronousSocketChannel,? super A> handler) 


它 的 第 一 个 参数 是 一 个 附件 ， 可 以 是 任意 类 型 ， 作 用 是 让 当前 线 
程 和 后 续 的 回调 方法 可 以 共享 信息 ， 它 会 在 后 续 调 用 中 ， 传 递 给 
handler 。 它 的 第 二 个 参数 是 CompletionHandler 接 口 。 这 个 接口 有 两 个 
方法 : 


void completed(V result, A attachment); 


void failed(Throwable exc, A attachment); 
这 两 个 方法 分 别 在 异步 操作 accept0 成 功 或 者 失败 时 被 回调 。 


此 AsynchronousServerSocketChannel.accept() 实际 上 做 了 两 件 
事 ， 第 一 是 发 起 accept 请 求 ， 告 诉 系 统 可 以 开始 监听 端口 了 。 第 二 ， 
注册 CompletionHandler 实 例 ， 告 诉 系统 ， 一 旦 有 客户 端 前 来 连接 ， 如 
果 成 功 连接 ， 束 去 执行 CompletionHandler.completed0) 方 法 ; 如 果 连 接 
失败 ， 就 去 执行 CompletionHandler.failed0 方 法 。 


所 以 ，serveraccept() 方 法 不 会 阻塞 ， 它 会 立即 返回 。 


下 面 ， 来 分 析 一 下 CompletionHandler.completed() 的 实现 。 当 
completed(Q RUTH, BRE CAA SP in MER T° TERT, 
使 A read0 方法 读 取 客户 的 数据 。 这 里 要 注意 ， 
AsynchronousSocketChannel.read0) 方 法 也 是 异步 的 ， 换 人 句 话 说 它 不 会 等 
待 读 取 完成 了 再 返回 ， 而 是 立即 返回 ， 返 回 的 结果 是 一 个 Future， 
此 这 里 就 是 Future 模 式 的 典型 应 用 。 为 了 编程 方便 ， 我 在 这 里 直接 调 


用 Future.get() 方 法 ， 进 行 等 待 ， 将 这 个 异步 方法 变 成 了 同步 方法 。 
此 ， 在 第 11 行 执行 完成 后 ， 数 据 读 取 束 已 经 完成 了 。 


Zia, BAPE SAR Po (1377) 。 这 里 调用 的 是 
AsynchronousSocketChannel.write() 方 法 。 这 个 方法 不 会 等 得 数据 全 音 
写 完 ， 也 是 立即 返回 的 。 同 样 ， 它 返回 的 也 是 Future 对 象 。 

再 之 后 ， 在 第 20 行 ， 服 务 器 进行 下 一 个 客户 端 连 接 的 准备 。 同 时 
关闭 当 前 正在 处 理 的 客户 端 连 接 。 但 在 关闭 之 前 ， 得 先 确保 之 前 的 
write0) 操 作 已 经 完成 ， 因 此 ， 使 用 Future.get(0 方 法 进行 等 待 (第 21 
ÍF) œ 
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务 器 了 : 


01 public static void main(String args[]) throws Exception { 


02 new AIOEchoServer().start(); 
03 // 主线 程 可 以 继续 目 己 的 行为 

04 while (true) { 

05 Thread.sleep(1000); 

06 } 

07 } 


上 述 代 码 第 2 行 ， 调 用 start() 方 法 开启 服务 器 。 但 由 于 start() 方 法 里 
使 用 的 都 是 异步 方法 ， 因 此 它 会 马上 返回 ， 它 并 不 像 阻 塞 方法 那样 会 
进行 等 待 。 因 此 ， 如 果 想 让 程序 驻守 执行 ， 第 4~6 行 的 等 待 语句 是 必 
需 的。 否则 ， 在 start() 方 法 结束 后 ， 不 等 客户 端 到 来 ， 程 序 已 经 运行 完 
成 ， 主 线程 束 将 退出 。 


5.11.2 AIO Echo 客户 端 实现 


在 服务 端的 实现 中 ， 我 们 使 用 Future.get() 方 法 将 异步 调用 转 为 了 
一 个 同步 等 待 。 在 客户 端的 实现 里 ， 我 们 将 全 部 使 用 异步 回调 实现 : 


01 public class AIOClient { 


02 public static void main(String[] args) throws Exception 
{ 
03 final AsynchronousSocketChannel client = 


AsynchronousSocketChannel.open(); 

04 client.connect(new InetSocketAddress("localhost", 8000), 
null, new CompletionHandler<Void, Object>() { 

05 @Override 

06 public void completed(Void result, Object 
attachment) { 

07 client.write(ByteBuffer.wrap("Hello!".getBytes()), null, 
new CompletionHandler<Integer, Object>() { 

08 @Override 

09 public void completed(Integer result, 
Object attachment) { 

10 try { 

11 ByteBuffer buffer = 
ByteBuffer.allocate(1024) ; 

12 client.read(buffer, buffer, new 
CompletionHandler<Integer, ByteBuffer>(){ 


13 @Override 


14 public void 
completed(Integer result, ByteBuffer buffer) { 

15 buffer.flip(); 

16 System.out.printin(new 


String(buffer.array())); 


17 try { 

18 client.close(); 

19 } catch (IOException e) 
{ 

20 e.printStackTrace(); 
21 } 

22 } 

23 @Override 

24 public void failed(Throwable 


exc, ByteBuffer attachment) { 


25 } 

26 }); 

27 } catch (Exception e) { 

28 e.printStackTrace(); 

29 } 

30 } 

31 @Override 

32 public void failed(Throwable exc, Object 


attachment) { 

33 } 
34 }); 
35 } 


36 @Override 
37 public void failed(Throwable exc, Object 


attachment) { 


38 } 

39 }); 

40 // 由 于 主线 程 马上 结束 ， 这 里 等 待 上 述 处 理 全 部 完成 
41 Thread.sleep(1000); 

42 } 

43 } 


上 面 的 AIO 客 户 端 看 起 来 代码 很 长 ， 但 实际 上 只 有 三 个 语句 。 


第 一 个 语句 为 第 3 行 ， 打开 AsynchronousSocketChannel 通 道 。 第 二 
个 语句 是 第 4~39 行 ， 它 让 客户 端 去 连接 指定 的 服务 器 ， 并 注册 了 一 系 
列 事件 。 第 三 个 语句 是 第 41 行 ， 让 线程 进行 等 待 。 虽 然 第 2 个 语句 看 起 
来 很 长 ， 但 是 它 完全 是 异步 的 ， 因 此 会 很 快 返回 ， 并 不 会 等 待 在 连接 
操作 的 过 程 中 。 如 果 不 进行 等 每 ， 客户 端 会 马上 退出 ， 也 束 无 法 继续 
AME = 


第 4 行 ， 客 户 端 进行 网 络 连接 ， 并 注册 了 连接 成 功 的 回调 函数 
CompletionHandler < Void, Object > 。 竺 连接 成 功 后 ， 束 会 进入 代码 第 7 
行 。 第 7 行进 行 数据 写 入 ， 回 服务 端 发 送 数据 。 这 个 过 程 也 是 异步 的 ， 
会 很 快 返回 。 写 入 完成 后 ， 会 通知 回调 接口 CompletionHandler< 
Integer, Object> ， 进 入 第 10 行 。 第 10 行 开始 ， 准 备 进行 数据 读 取 ， 从 
服务 端 读 取 回 写 的 数据 。 当 然 ， 第 12 行 的 read0 函 数 也 是 立即 返回 的 ， 
成 功 读 取 所 有 数据 后 ， 会 回调 CompletionHandler< Integer, ByteBuffer 
> 接口 ， 进 入 第 15 行 。 在 第 15~16 行 ， 打 印 接收 到 的 数据 。 
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第 6 章 Java 8 与 并 发 


2014 年 ，Oracle 发 布 了 Java 8 新 版 本 。 对 于 Java 来 说 ， 这 显然 是 一 
个 具有 里 程 碑 意 义 的 版 本 。 它 最 主要 的 改进 是 增加 了 函数 式 编程 的 功 
° 束 目 前 米 说 ，Java 最 令 人 头痛 的 问题 ， 也 是 受到 最 多 质疑 的 地 
， 应 该 束 是 Java 那 烦琐 的 语法 。 这 样 我 们 不 得 不 花费 大 量 的 代码 行 
， 来 实现 一 些 司空 见 惯 的 功能 ， 以 至 于 Java 程 序 总 是 见长 的 。 但 
， 这 一 切 将 在 Java 8 的 函数 式 编 程 中 得 到 缓解 。 


各 图 过 Rè 


产 格 来 说 ， 画 数 式 编程 与 我 们 的 主题 并 没有 太 大 关系， 我 似乎 不 
应 该 在 这 里 提 及 它 。 但 是 ， 在 Java 8 中 新 增 的 一 些 与 并 行 相关 的 API， 
却 以 函数 式 编 程 的 范式 出 现 ， 为 了 能 让 大 家 更 好 地 理解 这 些 功能 ， 我 
会 先 简要 地 介绍 一 下 Java 8 中 的 函数 式 编程 。 


6.1 Java BAJK TEIT 


函数 式 编 程 与 面 问 对 象 的 设计 方法 在 思路 和 手段 上 都 各 有 千秋 ， 
在 这 里 ， 我 将 简要 介绍 一 下 函数 式 编 程 与 面 同 对 象 相 比 较 的 一 些 特点 
和 差异 。 


6.1.1 ”函数 作为 一 等 公民 


在 理解 函数 作为 一 等 公民 这 和 句 话 时 ， 让 我 们 先 来 看 一 下 一 种 非常 
常用 的 互联 网 语言 JavaScript， 相 信 大 家 对 它 都 不 会 陌生 。JavaScript 并 
不 是 严格 意义 上 的 函数 式 编 程 ， 不 过 ， 它 也 不 是 属于 严格 的 面向 对 
象 。 但 是 ， 如 果 你 愿意 ， 你 既 可 以 把 它 当 作 面 癌 对 象 语 言 ， 也 可 以 把 
它 当 作 函 数 式 语言 ， 因 此 ， 称 之 为 多 范式 语言 ， 可 能 更 加 合适 。 


如 有 果 你 使 用 jQuery， 你 可 能 会 经 常 使 用 如 下 的 代码 : 


$("button").click(function(){ 
$("1i").each(function()£ 
alert($(this).text()) 
t)i 
t)i 
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节点 时 ， 会 弹出 i 市 点 的 文本 内 容 。 将 函数 作为 参数 传递 给 另外 一 个 
阔 数 ， 这 是 玉 数 式 编程 的 特性 之 一 。 


再 来 考察 另外 一 个 案例 : 


function f1(){ 
var n=1; 
function f2(){ 
alert(n); 
} 
return f2; 
} 
var result=f1(); 


result(); // 1 


这 也 是 一 段 JavaScript 人 代码。 在 这 段 代 码 中 ， 注 意 函 数 伍 的 返回 
值 ， 它 返回 了 函数 刀 。 在 倒数 第 2 行 ， 返 回 的 包 国 数 并 赋值 给 result， 实 
际 上 ， 此 时 的 result 束 是 一 个 范 数 ， 并 且 指 向 f2。 对 result 的 调用 ， 就 会 
打印 n 的 值 。 


玉 数 可 以 作为 另外 一 个 函数 的 返回 值 ， 也 是 函数 式 编 程 的 重要 特 
Ja? 


6.1.2 ”无 副作用 


函数 的 副作用 指 的 是 函 数 在 调用 过 程 中 ， 除 了 给 出 了 返回 值 外 ， 
还 修改 了 国 数 外 部 的 状态 。 比 如 ， 函 数 在 调用 过 程 中 ， 修 改 了 时 一 个 
全 局 状态 。 函数 式 编 程 认为 ， 函 数 的 副 用 作 应 该 被 尽量 避免 。 可 以 想 
象 ， 如 来 一 个 玉 数 肆意 修改 全 局 或 者 外 部 状态 ， 当 系统 出 现 问 题 时 ， 
我 们 可 能 很 难 判断 究竟 是 哪个 画 数 引起 的 问题 ， 这 对 于 程序 的 调试 和 


跟 踩 是 没有 好 处 的 。 如 果 画 数 都 是 显 式 函 数 ， 那 么 画 数 的 执行 显然 不 
会 受到 外 部 或 者 全 局 信息 的 影响 ， 因 此 ， 对 于 调试 和 排 错 是 有 花 的 。 


TER: 显 式 函 数 指 函数 与 外 界 交 换 数据 的 唯一 渠道 就 是 参数 和 返 
回 值 ， 显 式 函 数 不 会 去 读 取 或 者 修改 力 数 的 外 部 状态 。 与 之 相对 
的 是 隐 式 函数 ， 隐 式 了 画 数 除了 参数 和 返回 值 外 ， 还 会 读 取 外 部 信 
思 ， 或 者 可 能 修改 外 部 信息 。 


然而 ， 完 全 的 无 副作用 实际 上 做 不 到 的 ， 因 为 系统 总 是 需要 获取 
或 者 修改 外 部 信息 的 ， 同 时 ， 模 块 之 间 的 交互 也 极 有 可 能 是 通过 共有 至 
变量 进行 的 。 如 采 完 全 休止 副作用 的 出 现 ， 也 是 一 件 让 人 很 不 愉快 的 
事情 。 因 此 ， 大 部 分 函数 式 编 程 语言 ， 如 Clojure 等 ， 都 允许 副作用 的 
存在 。 但 古 与 面向 对 象 相 比 ， 这 种 函数 调用 的 副作用 ， 在 函数 式 编 程 
里 ， 需 要 进行 有 效 的 限制 。 


6.1.3 ”申明 式 的 (Declarative) 


函数 式 编 程 是 申明 式 的 编程 方式 。 相 对 于 命令 式 (Imperative) 而 
， 命 令 式 的 程序 设计 喜欢 大 量 使 用 可 变 对 象 和 指令 。 我 们 总 是 习惯 
于 创建 对 象 或 者 变量 ， 并 且 修 改 它 们 的 状态 或 者 值 ， 或 者 喜欢 提供 一 
系列 指令 ， 要 求 程 序 执行 。 这 种 编程 习惯 在 申明 式 的 函数 式 编程 中 有 
所 变化 。 对 于 申明 式 的 编程 范式 ， 你 不 再 需要 提供 明确 的 指令 操作 ， 
所 有 的 细节 指令 将 会 更 好 地 被 程序 库 所 封闭， 你 要 做 的 只 是 提出 你 的 
要 求 ， 申 明 你 的 用 意 即 可 。 


ll. 


请 看 下 面 一 段 程 序 ， 这 一 段 传统 的 命令 式 编程 ， 为 了 打印 数组 中 
的 值 ， 我 们 需要 进行 一 个 循环 ， 并 且 每 次 需要 判断 循环 是 否 结束 。 在 


循环 体内 ， 我 们 要 明确 地 给 出 需要 执行 的 语句 和 参数 。 


public static void imperative(){ 
int[] iArr={1,3,4,5,6,9,8,7,4,2}; 
for(int i1=0;i<iArr.length; i++) { 


System.out.println(iArr[i]); 


与 之 对 应 的 申明 式 代码 如 下 : 


public static void declarative(){ 
int[] 1Arr={1,3,4,5,6,9,8,7,4,2}; 


Arrays.stream(iArr).forEach(System.out::println); 


可 以 看 到 ， 变 量 数组 的 循环 体 居 然 消 失 了 ! printin0 函 数 似乎 在 这 
里 也 没有 指定 任何 参数 ， 在 此 ， 我 们 只 是 简单 地 申明 了 我 们 的 用 意 。 
有 关 循 环 以 及 判断 循环 是 否 结束 等 操作 都 被 简单 地 封 钱 在 程序 库 中 。 


6.1.4 ”不 变 的 对 象 


在 函数 式 编 程 中 ， 几 乎 所 有 传递 的 对 象 都 不 会 被 轻易 修改 。 
请 看 以 下 代码 : 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


Arrays.stream(arr).map((x)-> 


x=x+1).forEach(System.out::printin); 
System.out.printin(); 


Arrays.stream(arr).forEach(System.out::println); 


代码 第 2 行 看 似 对 每 一 个 数组 成 员 执行 了 加 1 的 操作 。 但 是 在 操作 
完成 后 ， 在 最 后 一 行 ， 打 印 ar 数 组 所 有 的 成 员 值 时 ， 你 还 是 会 发 现 ， 
数组 成 员 并 没有 变化 ! 在 使 用 函数 式 编程 时 ， 这 种 状态 是 一 种 常态 ， 
几乎 所 有 的 对 象 都 拒绝 被 修改 。 这 非常 类 似 于 不 变 模 式 。 


6.1.5 ATF 


由 于 对 和 象 都 处 于 不 变 的 状态 ， 因 此 函数 式 编程 更 加 易于 并 行 。 实 
际 上 ， 你 长 至 完全 不 用 担心 线程 安全 的 问题 。 我 们 之 所 以 要 关注 线程 
安全 ， 一 个 很 重要 的 原因 是 当 多 个 线程 对 同一 个 对 象 进行 写 操 作 时 
容易 将 这 个 对 象 “ 写 坏 ”。 但 是 ， 由 于 对 象征 不 变 的 ， 因 此 ， 在 多 线程 
环境 下 ， 也 就 没有 必要 进行 任何 同步 操作 。 这 样 不 仅 有 利于 并 行 化 ， 
同时 ， 在 并 行 化 后 ， 由 于 没有 同步 和 锁 机 制 ， 其 性 能 也 会 比较 好 。 


6.1.6 ”更 少 的 代码 


通常 情况 下 ， 函 数 式 编程 更 加 简明 扼要 ，Clojure 语 言 (一 种 运行 
于 JVM 的 函数 式 语言 ) 的 爱好 者 就 宣称 ， 使 用 Clojure 可 以 将 Java 代 码 
行 数 减少 到 原 有 的 十 分 之 一 。 一 般 说 来 ， 精 倘 的 代码 更 易于 维护 。 引 
入 函数 式 编程 范式 后 ， 我 们 可 以 使 用 Java 用 更 少 的 代码 完成 更 多 的 工 
作 。 


请 看 下 面 这 个 例子 ， 对 于 数组 中 每 一 个 成 员 ， 首 先 判 断 是 否 是 奇 
数 ， 如 果 是 奇数 ， 则 执行 加 1， 并 最 终 打印 数组 内 所 有 成 员 


[0] 


数组 定义 : 
static int[] arr={1,3,4,5,6,7,8,9,10}; 
传统 的 处 理 方 式 : 


for(int 1=0;i<arr.length;i++){ 
if (arr[i]%2!=0) { 
arr[i]++; 
} 


System.out.printiln(arr[i]); 


SEH KAEI EA: 


Arrays.stream(arr ).map(x- > (x%2==0? 


x:X+1)).forEach(System.out::println); 


HAER, KAREA ARM Bae ° 


6.2 ”函数 式 编 程 基础 


在 正式 进入 函数 式 编 程 之 前 ， 有 必要 先 了 解 一 下 Java 8 为 支持 函数 
式 编 程 所 做 的 基础 性 的 改进 ， 这里， 将 人 简要 介绍 一 下 
FunctionalInterface 注 释 、 接 口 默认 方法 和 方法 句柄 。 


6.2.1 FunctionalInterface 注 释 


Java 8 提出 了 画 数 式 接 口 的 概念 。 所 请 函数 式 接口 ， 位 单 来 说 ， 整 
是 只 定义 了 单一 抽象 方 法 的 接口 。 比 如 下 面 的 定义 : 


@FunctionalInterface 
public static interface IntHandler{ 


void handle(int i); 


注释 FunctionalInterface 用 于 表明 IntHandler 接 口 是 一 个 函数 式 接 
口 ， 该 接口 被 定义 为 只 包含 一 个 抽象 方法 handle0， 因 此 它 符 合 函 数 式 
接口 的 定义 。 如 果 一 个 函数 满足 函数 式 接口 的 定义 ， 那 么 即使 不 标注 
为 @FunctionalInterface， 编 译 属 依然 会 把 它 看 做 函数 式 接 口 。 这 有 点 
像 @Override 注 释 ， 如 采 你 的 函数 符合 重 载 的 要 求 ， 无 论 你 是 否 标注 了 
@Override， 编 译 怖 都 会 识别 这 个 重 载 范 数 ， 但 一 旦 你 进行 了 标注 ， 而 
实际 的 代码 不 符合 规范 ， 那 么 就 会 得 到 一 个 编译 错误 。 如 图 6.1 所 示 ， 
展示 了 一 个 不 符合 规范 ， 却 被 标注 为 @FunctionalInterfacede 接 口 。 很 
显然 ， 该 IntHandler 包 含 两 个 抽象 方法 ， 因 此 不 符合 函数 式 接口 的 要 


求 ， 又 因为 IntHandler 接 口 被 标 注 为 函数 式 接口 ， 产 生 矛 盾 ， 故 编译 出 


tH ° 


9 @FunctionalInterface 

10 public static interface IntHandler{ 
11 void handle(int i); 

12 void handle2(int i); 
13 } 


图 6-1 不 符合 规范 的 画 数 式 接口 


这 里 需要 强调 的 是 ， 画 数 式 接口 只 能 有 一 个 抽象 方法 ， 而 不 是 只 
能 有 一 个 方法 。 这 分 两 点 来 说 明 : 首先 ， 在 Java 8 中 ， 接 口 运 行 存在 实 
例 方法 (参见 下 市 的 “接口 默认 方法 ”) ， 其 次 任何 被 java.lang.Object 实 
现 的 方法 ， 都 不 能 视 为 抽象 方法 ， 因 此 ， 下 面 的 NonFunc 接 口 不 是 函 
数 式 接口 ， 因 为 equals() 方 法 在 java.lang.Object 中 已 经 实现 。 


interface NonFunc { 


boolean equals(Object obj); 


EHE, FP SE SWAY IntHandler# Hl #7 WATE BK, PAE 
来 它 不 像 ， 但 实际 上 它 是 一 个 完全 符合 规范 的 函数 式 接口 。 


@FunctionalInterface 
public static interface IntHandler{ 
void handle(int i); 


boolean equals(Object obj); 


函数 式 接 口 的 实例 可 以 由 方法 引用 或 者 lambda 表 达 式 进行 构造 ， 
这 个 我 们 将 在 后 面 进一步 举例 说 明 。 


6.2.2 ”接口 默认 方法 


在 Java 8 之 前 的 版 本 ， 接 口 只 能 包含 抽象 方法 。 但 从 Java 8 之 后 ， 
接口 也 可 以 包含 若干 个 实例 方法 。 这 一 改进 使 得 Java 8 拥有 了 类 似 于 多 
继承 的 能 力 。 一 个 对 象 实例 ， 将 拥有 来 目 于 多 个 不 同 接口 的 实例 方 
法 。 


比如 ， 对 于 接口 [Horse， 实 现 如 下 : 


public interface IHorse{ 
void eat(); 
default void run(){ 


System.out.printin("hourse run"); 


在 Java 8 中 ， 使 用 default 关 键 字 ， 可 以 在 接口 内 定义 实例 方法 。 注 
意 ， 这 个 方法 并 非 抽 象 方 法 ， 而 是 拥有 特定 逻辑 的 具体 实例 方法 。 


所 有 的 动物 都 能 目 由 呼吸 ， 所 以 ， 这 里 可 以 再 定义 一 个 IAnimal 接 
口 ， 它 也 包含 一 个 默认 方法 breathO 。 


public interface IAnimal { 
default void breath(){ 


System.out.printlin("breath"); 


骤 是 马 和 驴 的 杂交 物种 ， 因 此 又 (Mule) 可 以 实现 为 IHorse， 同 
时 又 也 是 动物 ， 因 此 有 : 


public class Mule implements IHorse, IAnimal{ 

@Override 

public void eat() { 
System.out.printin("Mule eat"); 

i 

public static void main(String[] args) { 
Mule m=new Mule(); 
m.run(); 


m.breath(); 


注意 上 述 代 码 中 Mule 实 例 同 时 拥有 来 目 不 同 接口 的 实现 方法 。 这 
在 Java 8 之 前 是 做 不 到 的 。 从 某 种 程度 上 说 ， 这 种 模式 可 以 弥补 Java 单 
一 继承 的 一 些 不 便 。 但 同时 也 要 知道 ， 它 也 将 遇 到 和 多 继承 相同 的 问 
题 ， 如 图 6.2 所 示 。 如 有 果 IDonkey 也 存在 一 个 默认 的 run0 方 法 ， 那 么 同 
时 实现 它们 的 Mule， 整 会 不 知 所 措 ， 因 为 它 不 知道 应 该 以 哪个 方法 为 
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图 6-2 ”接口 默认 方法 市 来 的 多 继承 问题 


增加 一 个 IDonkey 的 实现 : 


public interface IDonkey{ 
void eat(); 
default void run(){ 


System.out.println("Donkey run"); 


修改 又 Mule 的 实现 如 下 ， 注 意 它 同时 实现 了 IHorse 和 IDonkey: 


public class Mule implements IHorse,IDonkey,IAnimalf{ 
@Override 
public void eat() { 


System.out.printin("Mule eat"); 


} 

public static void main(String[] args) { 
Mule m=new Mule(); 
m.run(); 


m.breath(); 


此 时 ， 由 于 IHorse 和 IDonkey 拥 有 相同 的 默认 实例 方法 ， 故 编译 虱 
会 抛 出 一 个 错误 : 


Duplicate default methods named run with the parameters () and 
() are inherited from the types 


IDonkey and IHorse 


为 了 让 Mule 同 时 实现 IHorse 和 IDonkey， 在 这 里 ， 我 们 不 得 不 重新 
实现 一 下 run0 方 法 ， 让 编译 器 可 以 进行 方法 绑 定 。 修 改 Mule 的 实现 如 
下 : 


public class Mule implements IHorse,IDonkey,IAnimalf{ 
@Override 
public void run(){ 


IHorse.super.run(); 


@Override 

public void eat() { 
System.out.printin("Mule eat"); 

i 

public static void main(String[] args) { 
Mule m=new Mule(); 
m.run(); 


m.breath(); 


在 这 里 ， 将 Mule 的 run0) 方 法 委托 给 IHorse 实 现 ， 当 然 ， 大 家 也 可 
以 有 目 己 的 实现 。 


接口 默认 实现 对 于 整个 函数 式 编程 的 流 式 表达 非常 重要 。 比 如 ， 
大 家 熟悉 的 java.util.Comparator 接 口 ， 它 在 JDK 1.2 时 就 已 经 被 引入 ， 
用 于 在 排序 时 给 出 两 个 对 象 实例 的 具体 比较 逻辑 。 在 Java 8 中 ， 
Comparator 授 口 新 增 了 若干 个 默认 方法 ， 用 于 多 个 比较 絮 的 整合 。 其 
中 一 个 常用 的 默认 方法 如 下 : 


default Comparator<T> thenComparing(Comparator<? super T> 
other) { 
Objects. requireNonNull(other ); 
return (Comparator<T> & Serializable) (c1, c2) -> { 
int res = compare(ci, c2); 
return (res != 0) ? res : other.compare(c1, c2); 


i 


有 了 这 个 默认 方法 ， 在 进行 排序 时 ， 我 们 就 可 以 非常 方便 地 进行 
元 素 的 多 条 件 排序 ， 比 如 ， 如 下 代码 构造 一 个 比较 右 ， 它 先 按 照 字符 
串 长 度 排序 ， 继 而 按照 大 小 写 不 敏感 的 字母 顺序 排序 。 


Comparator <String> cmp = 
Comparator .comparingInt (String: :length) 


. thenComparing(String.CASE_INSENSITIVE_ORDER) ; 


6.2.3 lambda 表达 式 


lambda 表 达 式 可 以 说 是 函数 式 编 程 的 核心 。lambda 表 达 式 即 匿名 
函数 ， 它 是 一 段 没 有 画 数 名 的 函数 体 ， 可 以 作为 参数 直接 传递 给 相关 


的 调用 者 。lambda 表 达 式 极 大 地 增强 了 Java 语 言 的 表达 能 力 。 


下 例 展 示 了 lambda 表 达 式 的 使 用 ， 在 forEach() 琅 数 中 ， 传 入 的 整 
是 一 个 lambda 表 达 式 ， 它 完成 了 对 元 素 的 标准 输出 操作 。 可 以 看 到 这 
段 表 达 式 并 不 像 函 数 一 样 有 名 字 ， 非 常 类 似 匿 名 内 部 类 ， 它 只 是 简单 
地 摘 述 了 应 该 执行 的 代码 段 。 


List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6); 


numbers.forEach((Integer value) -> System.out.println(value) ) ; 


和 匿名 对 和 象 一 样 ，lambda 表 达 式 也 可 以 访问 外 部 的 局 部 变量 ， 如 
BATA: 


final int num = 2; 
Function<Integer, Integer> stringConverter = (from) -> from * 
num; 


System.out.printin(stringConverter.apply(3)); 


上 述 代 码 可 以 编译 通过 ， 正 常 执行 ， 并 输出 6。 与 匿名 内 部 对 象 一 
样 ， 在 这 种 情况 下 ， 外 部 的 num 变 量 必 须 申 明 为 fnal， 这 样 才能 保证 
在 lambda 表 达 式 中 合法 的 访问 它 。 


但 奇妙 的 是 ， 对 于 lambda 表 达 式 而 言 ， 即 使 去 择 上 述 的 final 定 
义 ， 程 序 依然 可 以 编译 通过 ! 但 干 万 不 要 以 为 这 样 你 束 可 以 修改 num 
的 值 了 。 实 际 上 ， 这 只 是 Java 8 做 了 一 个 掩 人 耳目 的 小 处 理 ， 它 会 目 动 
地 将 在 lambda 表 达 式 中 使 用 的 变量 视 为 final。 因此， 下 述 代 码 是 可 以 
编译 通过 的 : 


int num = 2; 
Function< Integer, Integer> stringConverter = (from) -> from * 
num; 


System.out.printin(stringConverter.apply(3)); 
但 是 ， 如 果 像 下 面 这 么 写 ， 就 不 行 : 


int num = 2; 
Function< Integer, Integer> stringConverter = (from) -> from * 
num; 

num++; 


System.out.printin(stringConverter.apply(3)); 
上 述 的 num++ 会 引起 一 个 编译 错误 : 


Local variable num defined in an enclosing scope must be final 


or effectively final 


6.2.4 方法 引用 


方法 引用 十 Java 8 中 提出 的 用 来 简化 lambda 表 达 式 的 一 种 手段 。 它 
通过 类 名 和 方法 名 来 定位 到 一 个 静态 方法 或 者 实例 方法 。 


方法 引用 在 Java 8 中 的 使 用 非常 灵活 。 总 的 来 说 ， 可 以 分 为 以 下 几 
种 。 


© ATA TATIESIAR: ClassName::methodName 
。 实例 上 的 实例 方法 引用 : instanceReference::methodName 


。 超 类 上 的 实例 方法 引用 : super::methodName 

。 类 型 上 的 实例 方法 引用 : ClassName::methodName 
。 构造 方法 引用 : Class::new 

。 数组 构造 方法 引用 : TypeName[]::new 


BG, 方法 引用 使 用 “::” 定 义 ,，“::” 的 前 半 部 分 表示 类 名 或 者 实例 
名 ， 后 半 部 分 表示 方法 名 称 。 如 果 是 构造 钞 数 ， 则 使 用 new 表 示 。 


下 例 展 示 了 方法 引用 的 基本 使 用 : 


public class InstanceMethodRef { 
public static void main(String[] args) { 
List<User> users=new ArrayList <User->(); 
for(int 1=1;1<10;i++){ 


users.add(new User(i, "billy"+Integer.toString(1))); 


users.stream().map(User::getName) .forEach(System.out::println); 


i 


对 于 第 1 个 方法 引用 “User::getName”， 表 示 User 类 的 实例 方法 。 在 
执行 时 ，Java 会 自动 识别 流 中 的 元 素 (这 里 指 User 实 例 ) 是 作为 调用 
目标 还 是 调用 方法 的 参数 。 在 “User::getName” 中 ， 显 然 流 内 的 元 素 都 
应 该 作为 调用 目标 ， 因 此 实际 上 ， 在 这 里 调用 了 每 一 个 User 对 象 实例 
的 getName() 方 法 ， 并 将 这 些 User 的 name 作 为 一 个 新 的 流 。 同 时 ， 对 于 
这 里 得 到 的 所 有 name， 使 用 方法 引用 System.out::printn 进 行 处 理 。 这 
里 的 System.out 为 PrintStream 对 象 实例 ， 因 此 ， 这 里 表示 System.out 实 


例 的 printin 方 法 ， 系 统 也 会 目 动 判断 ， 流 内 的 元 素 此 时 应 该 作为 方法 
的 参数 传 入 ， 而 不 是 调用 目标 。 


一 般 来 说 ， 如 采 使 用 的 是 静态 方法 ， 或 者 调用 目标 明确 ， 那 么 流 
内 的 元 素 会 目 动作 为 参数 使 用 。 如 采 函 数 引 用 表示 实例 方法 ， 并 且 不 
存在 调用 目标 ， 那 么 流 内 元 素 号 会 目 动 作为 调用 目标 。 


因此 ， 如 有 果 一 个 类 中 存在 同名 的 实例 方法 和 静态 钞 数 ， 那 么 编译 
妖 束 会 感到 很 困惑 ， 因 为 此 时 ， 它 不 知道 应 该 使 用 哪个 方法 进行 调 
用 。 它 既 可 以 选择 同名 的 实例 方法 ， 将 流 内 元 素 作 为 调用 目标 ， 也 可 
以 使 用 静态 方法 ， 将 流 元 聚 作为 参数 。 


请 看 下 面 的 例子 : 


public class BadMethodRef { 
public static void main(String[] args) { 
List<Double> numbers=new ArrayList <Double>(); 
for(int i=1;i<10;i++){ 


numbers .add(Double.value0f(i)); 


numbers.stream( ).map(Double: :toString).forEach(System.out::prin 
tin); 
i 


上 述 代 码 试图 将 所 有 的 Double 元 系 转 为 String 并 将 其 输出 ， 但 是 很 
不 幸 ， 在 Double 中 同时 存在 以 下 两 个 函数 : 


public static String toString(double d) 


public String toString() 


IERT, ITKA | A Sh LH Se AE, CRS TE SE 
时 束 会 抛 出 如 下 错误 : 


Ambiguous method reference: both toString() and 
toString(double) from the type Double are 


eligible 


FES | FA tH AY CA ae te Pe EN IC, BRAY User 
X: 


public class User{ 
private int id; 


private String name; 


public User(int id,String name){ 
this.id=id; 
this.name=name; 


} 
// 这 里 省 略 对 字段 的 setter 和 getter 


下 面 的 方法 引用 调用 了 User 的 构造 玉 数 : 


public class ConstrMethodRef { 
@FunctionalInterface 


interface UserFactory<U extends User> { 


U create(int id, String name); 


static UserFactory<User> uf=User: :new; 


public static void main(String[] args) { 
List<User> users=new ArrayList<User>(); 
for(int 1=1;1<10;i++){ 
users.add(uf.create(i, 
"billy"+Integer.toString(1i))); 
} 


users.stream().map(User::getName).forEach(System.out::println); 


} 


在 此 ，UserFactory 作 为 User 的 工厂 类 ， 是 一 个 函数 式 接口 。 当 使 
用 User:new 创 建 接口 实例 时 ， 系 统 会 根据 UserFactory.create0 的 函数 签 
名 来 选择 合适 的 User 构 造 画 数 ， 在 这 里 ， 很 显然 就 是 public User(int 
id,String name)。 在 创建 UserFactory 实 例 后 ， 对 UserFactory.create() 的 调 
用 ， 都 会 委托 给 User 的 实际 构造 钞 数 进行 ， 从 而 创建 User 对 象 实 例 。 


6.3 “一步 一 步 走 入 函数 式 编程 


在 了 解 了 Java 8 的 一 些 新 符 性 后 ， 束 可 以 正式 开始 进入 函数 式 编 程 
了 。 为 了 能 让 大 家 更 快 地 理解 函数 式 编 程 ， 我 们 先 从 位 单 的 例子 开 


始 。 
A 
static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
for(int i:arr){ 


System.out.println(1); 
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也 是 传统 的 做 法 。 如 果 使 用 Java 8 中 的 流 ， 那 么 可 以 写成 这 样 : 


he 


Static ant] ari = 1-1, 3, 4, 5, 6, 7, 8, Sp 10.3; 


public static void main(String[] args) { 
Arrays.stream(arr).forEach(new IntConsumer() { 
@Override 
public void accept(int value) { 


System.out.printin(value); 


P) 


注意 : Arrays.stream() 方 法 返回 了 一 个 流 对 象 。 类 似 于 集合 或 者 数 
组 ， 流 对 象 也 十 一 个 对 象 的 集合 ， 它 将 给 予 我 们 遇 历 处 理 流 内 元 
素 的 功能 。 


这 里 值得 注意 的 是 这 个 流 对 象 的 forEach() 方 法 ， 它 接收 一 个 
IntConsumer 接 口 的 实现 ， 用 于 对 每 个 流 内 的 对 象 进 行 处 理 。 之 所 以 是 
IntConsumer 接 口 ， 因 为 当前 流 是 IntStream， 也 就 是 装 有 Integer 元 素 的 
流 ， 因 此 ， 它 目 然 需 要 一 个 处 理 Integer 元 素 的 接口 。 画 数 forEachO) 会 
挨个 将 流 内 的 元 素 送 入 IntConsumer 进 行 处 理 ， 循 环 过 程 被 封装 在 
forEach() 内 部 ， 也 就 是 JDK 框 架 内 。 


除了 IntStream jit 外 ， Arrays.stream() 还 支持 DoubleStream ` 
LongStream 和 普通 的 对 象 流 Stream， 这 完全 取决 于 它 所 接受 的 参数 ， 
如 图 6.3 所 示 。 


stream 
4 ®© Arrays 

es stream(T[]) <T> : Stream<T> 
es stream(T[], int, int) <T> : Stream<T> 
es stream(int[]}) : IntStream 
es stream(int{], int, int) : IntStream 
es stream(long[]) : LongStream 
es stream(long[], int, int) : LongStream 
es stream(double[]) : DoubleStream 
es stream(double{], int, int) : DoubleStream 


图 6.3 ”Stream 流 的 几 种 类 型 


但 这 样 的 写法 可 能 还 不 能 让 人 满意 ， 代 码 量 似乎 比 原先 更 多 ， 而 
且 除了 引入 了 不 必要 的 接口 和 匿名 类 等 复杂 性 外 ， 似 乎 也 看 不 出 来 有 
什么 太 大 的 好 处 。 但 是 ， 我 们 的 脚步 并 未 惑 此 打住 。 试 想 ， 既 然 
forEachO 函 数 的 参数 是 可 以 从 上 下 文中 推导 出 来 的 ， 那 为 什么 还 要 不 
大 其 烦 地 写 出 来 呢 ? 这 些 机 械 的 推导 工作 ， 束 交 给 编译 亏 去 做 吧 ! 于 


H 
JE: 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
Arrays.stream(arr).forEach((final int x)-> { 
System.out.println(x); 
t); 


从 上 述 代 码 中 可 以 看 到 ，IntSstream 接 口 名 称 被 省 略 了 ， 这 里 只 使 
用 了 参数 名 和 一 个 实现 体 ， 看 起 来 简洁 很 多 了 。 但 是 还 不 够 ， 因 为 参 
数 的 类 型 也 是 可 以 推导 的 。 既 然 是 IntConsumer 接 口 ， 参 数目 然 是 int 
T, FÆ: 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
Arrays.stream(arr).forEach((x)-> { 
System.out.println(x); 
t); 


好 了 ， 现 在 连 参数 类 型 也 省 略 了 ， 但 征 这 两 个 伦 括 号 特别 碍 眼 。 
虽然 它们 对 程序 没有 什么 影响 ， 但 是 为 了 简单 的 一 句 执行 语句 要 加 上 
一 对 人 花 插 号 也 实 属 没有 必要 ， 那 干脆 也 去 挥 吧 ! 去 掉 花 括号 后 ， 为 了 
清晰 起 见 ， 把 参数 申明 和 接口 实现 就 放 在 一 行 吧 ! 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 


Arrays.stream(arr).forEach((x)->System.out.printin(x)); 


这 样 看 起 来 就 好 多 了 。 此 时 ，forEach0) 函 数 的 参数 依然 是 
IntConsumer， 但 是 它 却 以 一 种 新 的 形式 被 定义 ， 这 就 是 lambda 表 达 
式 。 表 达 式 由 “-> ”分割 ， 左 半 部 分 表示 参数 ， 右 半 部 分 表示 实现 体 。 
因此 ， 我 们 也 可 以 简单 地 理解 lambda 表 达 式 只 是 匿名 对 象 实现 的 一 种 
新 的 方式 。 实 际 上 ， 也 是 这 样 的 。 


有 兴趣 的 读者 可 以 使 用 虚拟 机 参数 - 
Djdk.internal.lambda.dumpProxyClasses 局 动 融 有 lambda 表 达 式 的 Java 小 
程序 ， 该 参数 会 将 lambda 表 达 式 相关 的 中 间 类 型 进行 输出 ， 方 便 调 试 
和 学 习 。 在 本 例 中 ， 输 出 了 HelloFunction6$$Lambda$1.class 类 ， 使 用 
以 下 命令 进行 并 发 汇编 操作 : 


javap -p -v HelloFunction6$$Lambda$1.class 


在 输出 结果 中 ， 可 以 清楚 地 看 到 |: 


final class geym. java8.func.ch3.HelloFunction6$$Lambda$1 


implements 


java.util.function.IntCconsumer 
省 略 部 分 输出 


public void accept(int); 


descriptor: (I)V 
flags: ACC_PUBLIC 
Code: 
stack=1, locals=2, args_size=2 
0: iload 1 
1: invokestatic #17 // Method 
geym/java8/func/ch3/HelloFunction6.lambda$0:(I)V 


4: return 


限于 篇 幅 有 限 ， 这 里 只 给 出 了 我 们 关心 的 内 容 。 首 先 ， 这 个 中 间 
类 型 确实 实现 了 IntConsumer 接 口 。 其 次 ， 在 实现 accept0 方 法 时 ， 它 内 
部 委托 给 了 一 个 名 为 HelloFunction6.lambda$00 的 方法 。 可 以 推测 ， 这 
个 方法 也 是 编译 时 目 动 生成 的 。 


使 用 以 下 命令 查看 HelloFunction6 的 编译 结果 : 


javap -p -v HelloFunction6 


我 们 很 惊喜 地 找到 了 期 竺 已 久 的 lambda$00 方 法 ， 其 实现 如 下 : 


private static void lambda$0(int); 
descriptor: (I)V 
flags: ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC 
Code: 


stack=2, locals=1, args_size=1 


0: getstatic #41 // Field 
java/lang/System.out:Ljava/io/PrintStream; 
3: iload 0 
4: invokevirtual #47 // Method 
java/io/PrintStream.println: (I)V 


7: return 


它 补 实现 为 一 个 私有 的 静态 方法 ， 实 现 内 容 就 是 简单 地 进行 了 
System.out.println() 的 调用 ， 也 正 是 我 们 代码 中 lambda 表 达 式 的 内 容 。 


由 此 ， 可 以 看 到 ，Java 8 中 对 lambda 表 达 式 的 处 理 几 乎 等 同 于 匿名 
类 的 实现 ， 但 是 在 写法 上 和 编程 范式 上 有 了 明显 的 区 别 。 


不 过 ， 简 化 代码 的 流程 并 没有 结束 ， 在 上 一 下 中 已 经 所 到 ，Java 8 
还 文 持 了 方法 引用 ， 通 过 方法 引用 的 推导 ， 你 甚至 连 参 数 申 明和 传递 
都 可 以 省 略 。 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 


Arrays.stream(arr).forEach(System.out::println) ; 


至 此 ， 欢 迎 大 家 正式 进入 Java SERRE, ASML Kw 
的 lambda 表 达 式 的 解析 和 工作 原理 已 经 介绍 完毕 。 


使 用 lambda 表 达 式 不 仅 可 以 人 简化 匿名 类 的 编写 ， 与 接口 的 默认 方 
法 相 结合 ， 还 可 以 使 用 更 顺畅 的 流 式 API 对 各 种 组 件 进行 更 目 由 的 凑 
配 。 


下 面 这 个 例子 对 集合 中 所 有 元 到 进行 两 次 输出 ， 一 次 输出 到 标准 
背 误 ， 一 次 输出 到 标准 输出 中 。 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
IntConsumer outprintln=System.out::printin; 
IntConsumer errprintln=System.err::printin; 


Arrays.stream(arr).forEach(outprintin.andThen(errprintln) ); 


这 里 首先 使 用 函数 引用 ， 和 直接 定义 了 两 个 IntConsumer 接 口 实例 ， 
一 个 指向 标准 输出 ， 男 一 个 指 问 标准 错误 。 使 用 接口 默认 函数 
IntConsumer.addThen()， 将 两 个 IntConsumer 进 行 组 合 ， 得 到 一 个 新 的 
IntConsumer， 这 个 新 的 IntConsumer 会 依次 调用 outprintIn 和 errprintln， 


完成 对 数组 中 元 素 的 处 理 。 


其 中 IntConsumeraddThen0 的 实现 如 下 ， 仅 供 大 家 参考 : 


default IntConsumer andThen(IntConsumer after) { 
Objects.requireNonNull(after ); 


return (int t) -> { accept(t); after.accept(t); }; 


可 以 看 到 ，addThen0 方 法 返回 一 个 新 的 PntConsumer ， 这 个 新 的 
IntConsumer 会 先 调用 第 1 个 IntConsumer 进 行 处 理 ， 接 着 调用 第 2 个 
IntConsumer 处 理 ， 从 而 实现 多 个 处 理 器 的 整合 。 这 种 操作 手法 在 Java 
8 的 函数 式 编 程 中 极其 常见 ， 请 大 家 留意 。 


6.4 ”并行 流 与 并 行 排序 


Java 8 中 ， 0 将 流 改 为 并 行 流 。 这 样 ， 丈 
可 以 很 目 然 地 使 用 多 线程 进行 集合 中 的 数据 处 理 。 


6.4.1 使 用 并 行 流 过 滤 数 据 


现在 让 我 们 考虑 这 么 一 个 简单 的 案例 ， 我 们 希望 可 以 统计 1~ 
1000000 内 所 有 的 质数 的 数量 。 首 和 完 ， 我 们 需要 一 个 判断 质数 的 函数 : 


public class PrimeUtil { 
public static boolean isPrime(int number) { 

int tmp = number; 

if (tmp < 2) { 
return false; 

} 

for (int i = 2; Math.sqrt(tmp) >= i; i++) { 
if (tmp % i == 0) { 


return false; 


3 


return true; 


上述 本 数 给 定 一 个 数字 ， 如 果 这 个 数字 是 质数 就 返回 true， 人 否则 
巡回 false。 


接着 ， 使 用 函数 式 编 程 统计 给 定 范围 内 所 有 的 质数 : 


IntStream.range(1, 1000000).filter(PrimeUtil: :isPrime).count(); 
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数 ， 只 选择 所 有 的 质数 ， 最 后 进行 数量 统计 。 


上 述 代 码 是 率 行 的 ， 将 它 改造 成 并 行 计算 非常 和 宙 单 ， 只 需要 将 流 
并 行 化 即 可 : 


IntStream.range(1, 


1000000) .parallel().filter(PrimeUtil: :isPrime).count(); 


上 述 代 码 中 ， 首 先 parallel0 方 法 得 到 一 个 并 行 流 ， 接 着 ， 在 并 行 
流 上 进行 过 滤 ， 此 时 ，PrimeUtilisPrime() 落 数 会 被 多 线程 并 发 调用 ， 
应 用 于 流 中 的 所 有 元 素 。 


6.4.2 ”从 集合 得 到 并 行 尝 


在 函数 式 编程 中 ， 我 们 可 以 从 集合 得 到 一 个 流 或 者 并 行 流 。 下 面 
这 段 代 码 试图 统计 集合 内 所 有 学 生 的 平均 分 : 
List<Student> ss=new ArrayList<Student>(); 


double ave=ss.stream().mapToInt(s- > 


s.score) .average().getAsDouble(); 


从 集合 对 象 List 中 ， 我 们 使 用 stream0) 方 法 可 以 得 到 一 个 流 。 如 果 
硕 望 将 这 段 代 码 并 行 化 ， 则 可 以 使 用 parallelStream0O 函 数 。 


double ave=ss.parallelStream().mapToInt(s- > 


s.score) .average().getAsDouble(); 


可 以 看 到 ， 将 原 有 的 第 行 方式 改造 成 并 行 执行 是 非常 容易 的 。 


6.4.3 ”并 行 排 序 


除了 并 行 流 外 ， 对 于 普通 数组 ，Java 8 中 也 提供 了 人 简单 的 并 行 功 
能 。 比 如 ， 对 于 数组 排序 ， 我 们 有 Arrays.sort(0) 方 法 。 当 然 这 是 串 行 排 
序 ， 但 在 Java 8 中 ， 我 们 可 以 使 用 新 增 的 Arrays. parallelSort() 方 法 直接 
使 用 并 行 排序 。 


比如 ， 你 可 以 这 样 使 用 : 


int[] arr=new int[10000000]; 


Arrays.parallelSort(arr); 


除了 并 行 排序 外 ，Arrays 中 还 增加 了 一 些 API 用 于 数组 中 数据 的 赋 
值 ， 比 如 : 


public static void setAll(int[] array, IntUnaryOperator 


generator ) 


ee PS RAE IRR, EM B2TSSRCE—T BE 
口 。 如 采 我 们 想 给 数组 中 每 一 个 元 素 都 附 上 一 个 随机 值 ， 则 可 以 这 人 么 


做 : 


Random r=new Random( ) ; 


Arrays.setAll(arr, (1)->r.nextInt()); 


当然 ， 以 上 过 程 是 串 行 的 。 但 是 只 要 使 用 setAll0 对 应 的 并 行 
本 ， 你 瓯 可 以 很 快 将 它 执行 在 多 个 CPU 上 : 


Random r=new Random(); 


Arrays.parallelSetAll (arr, (1)->r.nextInt()); 


6.5 eG 强 HY Future : 


CompletableFuture 


CompletableFuture Java 8 新 增 的 一 个 超大 型 工具 类 。 为 什么 说 它 
Ave? 因为 一 方面 ， 它 实现 了 Future 接 口 ， 而 更 重要 的 是 ， 它 也 实现 
了 CompletionStage 接 口 。CompletionStage 接 口 也 是 在 Java 8 中 新 增 的 。 
而 CompletionStage 接 口 拥 有 多 达 约 40 种 方法 ! 是 的 ， 你 没有 看 错 ， 这 
看 起 来 完全 不 符合 设计 原则 中 所 谓 的 “单方 法 接口 ”， 但 是 在 这 里 ， 它 
就 这 么 存在 了 。 这 个 接口 之 所 以 拥有 如 此 众多 的 方法 ， 是 为 了 函数 式 
编程 中 的 流 式 调用 准备 的 。 通 过 CompletionStage 提 供 的 接口 ， 我 们 可 
以 在 一 个 执行 结果 上 进行 多 次 流 式 调用 ， 以 此 可 以 得 到 最 终结 采 。 比 
如 ， 你 可 以 在 一 个 CompletionStage 上 进行 如 下 调用 : 


stage.thenApply(x -> square(x)).thenAccept (x -> 
System.out.print(x)).thenRun(() -> 


System.out.println()) 
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6.5.1 E T ENR 


CompletableFuture 和 和 Future 一样 ， 可 以 作为 函数 调用 的 契约 。 如 果 
你 加 CompletableFuture 请 求 一 个 数据 ， 如 果 数 据 还 没有 准备 好 ， 请 求 
线程 吏 会 等 待 。 而 让 人 怀 喜 的 是 ， 通 过 CompletableFuture， 我 们 可 以 
手动 设置 CompletableFuture 的 完成 状态 。 


01 public static class AskThread implements Runnable { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
KET 
18 
19 


CompletableFuture<Integer> re = null; 


public AskThread(CompletableFuture<Integer> re) { 


this.re = re; 


@Override 
public void run() { 
int myRe = 0; 
try { 
myRe = re.get() * re.get(); 
} catch (Exception e) { 


t 
System.out.println(myRe); 


public static void main(String[ ] 


InterruptedException { 


20 


final CompletableFuture< Integer > 


CompletableFuture< >(); 


2i 
22 
23 
24 


new Thread(new AskThread(future)).start(); 
// 模拟 长 时 间 的 计算 过 程 

Thread.sleep(1000) ) 

// 告知 完成 结果 


args) 


future 


throws 


= new 


25 future.complete(60); 
26 } 


上 述 代 码 在 第 1~17 行 ， 定 义 了 一 个 AskThread 线 程 。 它 接收 一 个 
CompletableFuture 作 为 其 构造 男 数 ， 它 的 任务 是 计算 CompletableFuture 
表示 的 数字 的 平方 ， 并 将 其 打印 。 


代码 第 20 行 ， 我 们 创建 一 个 CompletableFuture 对 象 实例 ， 第 21 
行 ， 我 们 将 这 个 对 象 实例 传递 给 这 个 AskThread 线 程 ， 并 局 动 这 个 线 
程 。 此 时 ，AskThread 在 执行 到 第 12 行 代码 时 会 阻塞， 因为 
CompletableFuture 中 根本 没有 它 所 需要 的 数据 ， 整 个 CompletableFuture 
处 于 未 完成 状态 。 第 23 行 用 于 模拟 长 时 间 的 计算 过 程 。 当 计算 完成 
后 ， 可 以 将 最 终 数据 载 入 CompletableFuture， 并 标记 为 完成 状态 (第 
2547) ° 


当 第 25 行 代码 执行 后 ， 表 示 CompletableFuture 已 经 完成 ， 因 此 
AskThread 束 可 以 继续 执行 了 。 


6.5.2 ”异步 执行 任务 


通过 CompletableFuture 提 供 的 进一步 封装 ， 我 们 很 容易 实现 Future 
模式 那样 的 异步 调用 。 比 如 : 


01 public static Integer calc(Integer para) { 
02 try { 

03 // 模拟 一 个 长 时 间 的 执行 

04 Thread.sleep(1000); 


05 } catch (InterruptedException e) { 


06 } 

07 return para*para; 

08 } 

09 

10 public static void main(String[ | args) throws 


InterruptedException, ExecutionException 


由 

11 final CompletableFuture<Integer> future = 

12 CompletableFuture.supplyAsync(() -> calc(50)); 
13 System.out.println(future.get()); 

14 } 


上 述 代码 中 ， 第 11 一 12 行 使 用 CompletableFuture.supplyAsync0) 方 
法 构造 一 个 CompletableFuture 实 例 ， 在 supplyAsync0 落 数 中 ， 它 会 在 
一 个 新 的 线程 中 ， 执 行 传 入 的 参数 。 在 这 里 ， 它 会 执行 calc() 方 法 。 而 
calc(0 方 法 的 执行 可 能 是 比较 慢 的 ， 但 是 这 不 影响 CompletableFuture 实 
例 的 构造 速度 ， 因 此 supplyAsyncO 会 立即 返回 ， 它 返回 的 
CompletableFuture 对 象 实 例 束 可 以 作为 这 次 调用 的 站 约 ， 在 将 来 任何 
场合 ， 用 于 获得 最 终 的 计算 结果 。 代 码 第 13 行 ， 试 图 获得 calc() 的 计算 
结果 ， 如 采 当 前 计算 没有 完成 ， 则 调用 get( 方 法 的 线程 束 会 等 待 。 


在 CompletableFuture 中 ， 类 似 的 工厂 方法 有 以 下 几 个 : 


static <U> CompletableFuture<U> supplyAsync(Supplier <U> 
supplier); 
static <U> CompletableFuture<U>  supplyAsync(Supplier <U> 


supplier, Executor executor); 


static CompletableFuture<Void> runAsync(Runnable runnable); 
static CompletableFuture<Void>  runAsync(Runnable runnable, 


Executor executor); 


其 中 supplyAsync(0 方 法 用 于 那些 需要 有 返回 值 的 场景 ， 比 如 计算 
某 个 数据 等 + 。 而 runAsync0 方 法 用 于 没有 返回 值 的 场景 ， 比 如 ， 仅 仅 
是 人 简单 地 执行 某 一 个 异步 动作 。 


在 这 两 对 方法 中 ， 都 有 一 个 方法 可 以 接收 一 个 Executor 人 参数 。 这 
WEE Be) Ay LAE Supplier <U> 或 者 Runnable 在 指定 的 线程 池 中 工作 。 
如 果 不 指定 ， 则 在 默认 的 系统 公共 的 ForkJoinPool.common 线 程 池 中 的 
行 。 


注意 : 在 Java 8 中 ， 新 u commonPool0 方 法 。 它 可 
lone 个 公共 线程 池 中 的 所 有 线 
程 都 是 Daemon 线 程 。 这 意味 着 如 果 en Ri, ， 这 些 线程 无 论 是 
否 执行 完毕 ， 都 会 退出 系统 。 


6.5.3 ” 流 式 调用 


在 前 文中 我 已 经 简单 的 提 到 ，CompletionStage 的 约 40 个 接口 是 为 
函数 式 编程 做 准备 的 。 在 这 里 ， 束 让 我 们 看 一 下 ， 如 何 使 用 这 些 接口 
进行 函数 式 的 流 式 API 调 用 : 


01 public static Integer calc(Integer para) { 
02 try { 
03 // 模拟 一 个 长 时 间 的 执行 


04 Thread.sleep(1000); 


05 } catch (InterruptedException e) { 

06 } 

07 return para*para; 

08 } 

09 

10 public static void main(String[ ] args) throws 


InterruptedException, ExecutionException 


{ 
11 CompletableFuture<Void> 


fu=CompletableFuture.supplyAsync(() -> calc(50) ) 


12 . thenApply((1)->Integer.toString(i) ) 
13 .thenApply((str)->"\""+str+"\"") 

14 .thenAccept(System.out::println); 

15 fu.get(); 

16 } 


上 述 代 码 中 ， 使 用 supplyAsync() 函 数 执行 一 个 异步 任务 。 接 看 连 
续 使 用 流 式 调用 对 任务 的 处 理 结果 进行 再 加 工 ， 直 到 最 后 的 结果 和 输 
is 


这 里 ， 我 们 在 第 15 行 执行 CompletableFuture.get() 方 法 ， 目 的 是 等 
fF calc) 函数 执行 完成 。 如 有 果 不 进 行 这 个 等 竺 调用， 由 于 
CompletableFuture 异 步 执 行 的 缘故 ， 主 函数 不 等 calc(0) 方 法 执行 完毕 就 
会 退出 ， 随 着 主线 程 的 结束 ， 所 有 的 Daemon 线 程 都 会 立即 退出 ， 从 而 
导致 calc() 方 法 无 法 正常 完成 。 


6.5.4 ”CompletableFuture 中 的 异常 处 
理 


如 果 CompletableFuture 在 执行 过 程 中 遇 到 异常 ， 我 们 可 以 用 函数 
式 编程 的 风格 来 优雅 地 处理 这 些 异 常 。CompletableFuture 提 供 了 一 个 
异常 处 理 方法 exceptionally(): 


01 public static Integer calc(Integer para) { 


02 return para / 0; 

03 } 

04 

05 public static void main(String[] args) throws 


InterruptedException, ExecutionException { 


06 CompletableFuture<Void> fu = CompletableFuture 
07 .supplyAsync(() -> calc(50)) 

08 .exceptionally(ex -> { 

09 System.out.println(ex.toString()); 
10 return 0; 

11 }) 

12 .thenApply( (i) -> Integer.toString(i)) 
13 -EnNenAppLYC(SEr) Sm 
14 . thenAccept(System.out::printlin); 

iS fu.get(); 


16 } 


在 上 述 代 码 中 ， 第 8 行 对 当前 的 CompletableFuture 进 行 异常 处 理 。 
如 果 没 有 异常 发 生 ， 则 CompletableFuture 束 会 返回 原 有 的 结果 。 如 果 
遇 到 了 异常 ， 就 可 以 在 exceptionally0 中 处 理 异 常 ， 并 返回 一 个 默认 的 
值 。 在 上 例 中 ， 我 们 名 略 了 异常 堆栈 ， 只 是 简单 地 打印 异常 的 信息 。 


执行 上 述 函 数 ， 我 们 将 得 到 输出 : 


java.util.concurrent.CompletionException: 
java.lang.ArithmeticException: / by zero 


"o" 


6.5.5 组合 多 个 CompletableFuture 


CompletableFuture 还 允许 你 将 多 个 CompletableFuture 进 行 组 合 。 一 
种 方法 是 使 用 thenCompose()， 它 的 签名 如 下 : 


public <U> CompletableFuture<U> thenCompose(Function<? super 
T, ? extends 


CompletionStage<U> > fn) 


一 个 CompletableFuture 可 以 在 执行 完成 后 ， 将 执行 结果 通过 
Function 传 递 给 下 一 个 CompletionStage 进 行 处 理 (Function 接 口 返回 新 
的 CompletionStage 实 例 ) : 


01 public static Integer calc(Integer para) { 
02 return para/2; 

03 } 

04 


05 public static void main(String[ ] args) throws 


InterruptedException, ExecutionException { 


06 CompletableFuture<Void> fu = 
07 CompletableFuture.supplyAsync(() -> calc(50)) 
08 . thenCompose( (i) - > 


CompletableFuture.supplyAsync(() -> calc(i))) 

09 .thenApply((str)->"\"" + str + 
nm"), thenAccept(System.out::println); 

10 fu.get(); 

11 } 


上 述 代 码 第 8 行 ， 将 处 理 后 的 结果 传递 给 thenCompose0 ， 并 进 一 
步 传递 给 后 续 新 生成 的 CompletableFuture 实 例 。 以 上 代码 的 输出 如 
下 : 


" 12 " 


另外 一 种 组 合 多 个 CompletableFuture 的 方法 是 henCombine0 ， 它 
的 签名 如 下 : 


public <U,V> CompletableFuture<V> thenCombine 
(CompletionStage<? extends U> other, 


BiFunction<? super T,? super U,? extends V> fn) 


方法 thenCombine() 首 先 完成 当前 CompletableFuture 和 other 的 执 
行 。 接 着 ， 将 这 两 者 的 执行 结果 传递 给 BiFunction (该 接口 接收 两 个 参 
数 ， 并 有 一 个 返回 值 ) ， 并 返回 代表 BiFunction 实例 的 
CompletableFuture 对 象 : 


01 public static Integer calc(Integer para) { 


02 return para / 2; 

03 } 

04 

05 public static void main(String[] args) throws 
InterruptedException, ExecutionException { 

06 CompletableFuture< Integer > intFuture = 
CompletableFuture.supplyAsync(() -> calc(50)); 

07 CompletableFuture< Integer > intFuture2 = 
CompletableFuture.supplyAsync(() -> calc(25)); 

08 

09 CompletableFuture<Void> fu = 


intFuture.thenCombinet(intFuture2, (i, j) -> (i + j)) 


10 .thenApply( (str) -> "\"" + str + "\"") 
11 .thenAccept(System.out::println); 

12 fu.get(); 
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上 述 代 码 中 ， 首 先生 成 两 个 CompletableFuture 实 例 (486~7 
ÍT) ， 接 着 使 用 thenCombine0 组 合 这 两 个 CompletableFuture ， 将 两 者 
的 执行 结果 进行 票 加 (由 第 9 行 的 (i, j) -> (i+j) 实 现 ) ， 并 将 其 累加 结 


果 转 为 字符 串 ， 并 输出 。 上 述 代 码 的 输出 古 : 


Mey 


6.6” 读 写 锁 的 改进 : StampedLock 


StampedLock 是 Java 8 中 引入 的 一 种 新 的 锁 机 制 。 简 单 的 理解 ， 可 
以 认为 它 是 读 写 锁 的 一 个 改进 版 本 。 读 写 锁 虽然 分 离 了 读 和 写 的 功 
能 ， 使 得 读 与 读 之 间 可 以 完全 并 发 。 但 是 ， 读 和 写 之 间 依 然 是 冲突 
的 。 访 锁 会 完全 阻塞 写 锁 ， 它 使 用 的 依然 是 悲观 的 锁 策 略 ， 如 果 有 大 
量 的 读 线 程 ， 它 也 有 可 能 引起 写 线程 的 “只 饿 ”。 


而 StampedLock 则 提供 了 一 种 乐观 的 读 案 略 。 这 种 乐观 的 锁 非 常 
类 似 无 锁 的 操作 ， 使 得 乐观 锁 完 全 不 会 阻塞 写 线程 。 


6.6.1 ”StampedLock 使 用 示例 


StampedLock 的 使 用 并 不 困难 ， 下 面 是 StampedLock 的 使 用 示例 : 


01 public class Point { 


02 private double x, y; 

03 private final StampedLock sl = new StampedLock()j; 

04 

05 void move(double deltaX, double deltaY) { LE 
是 一 个 排 它 锁 

06 long stamp = sl.writeLock(); 

07 try { 

08 x += deltax; 


09 y += deltaY; 


10 } finally { 


11 sl.unlockwrite(stamp) ; 

12 } 

13 } 

14 

15 double distanceFromorigin() { // Rika 
法 

16 long stamp = sl.tryOptimisticRead(); 

17 double currentX = x, currentY = y; 

18 if (!sl.validate(stamp)) { 

19 stamp = sl.readLock(); 

20 Cryst 

21 currentX = x; 

22 currentyY = y; 

23 } finally { 

24 sl.unlockRead(stamp); 

25 y 

26 } 

27 return Math.sqrt(currentX * currentX + currentY * 


currentyY ) ; 
28 } 
29 } 


上 述 代 码 出 目 JDK 的 官方 文档 。 它 定义 了 一 个 点 Point 类 ， 内 部 有 
两 个 元 素 x 和 y， 表 示 点 的 坐标 。 第 3 行 ， 定义 了 StampedLock 锁 。 第 15 
行 定义 的 distanceFromOrigin() 方 法 是 一 个 只 读 方 法 ， 它 只 会 读 取 Point 
的 x 和 y 侍 标 。 在 读 取 时 ， 首 先 使 用 了 StampedLock.tryOptimisticRead() 


方法 。 这 个 方法 表示 试图 党 试 一 次 乐观 读 。 它 会 返回 一 个 类 似 于 时 间 
惟 的 邮 鹤 整数 stamp。 这 个 stamp 职 可 以 作为 这 一 次 锁 获 取 的 凭证 。 


接着 ， 在 第 17 行 ， 读 取 x 和 y 的 值 。 当 然 ， 这 时 我 们 并 不 确定 这 个 x 
和 y 是 否 是 一 致 的 〈 在 读 取 x 的 时 候 ， 可 能 其 他 线程 改写 了 y 的 值 ， 使 得 
currentX 和 currentY 处 于 不 一 致 的 状态 ) ， 因 此 ， 我 们 必须 在 第 18 行 ， 
使 用 validate0) 方 法 ， 判 断 这 个 stamp 是 否 在 读 过 程 发 生 期 间 被 修改 过 。 
如 采 stamp 没 有 被 修改 过 ， 则 认为 这 次 读 取 是 有 效 的 ， 因 此 残 可 以 跳 转 
到 第 27 行 ， 进 行 数据 处 理 。 反 之 ， 如 果 stamp 是 不 可 用 的 ， 则 意味 着 在 
读 取 的 过 程 中 ， 可 能 被 其 他 线程 改写 了 数据 ， 因 此 ， 有 可 能 出 现 了 脏 
读 。 如 果 出 现 这 种 情况 ， 我 们 可 以 像 处 理 CAS 操 作 那 样 在 一 个 死 循 环 
中 一 直 使 用 乐观 读 ， 直 到 成 功 为 止 。 


也 可 以 升级 锁 的 级 别 。 在 本 例 中 ， 我 们 升级 乐观 锁 的 级 别 ， 将 乐 
观 锁 变 为 悲观 锁 。 在 第 19 行 ， 当 判断 乐观 读 失败 后 ， 使 用 readLockO 获 
得 悲观 的 读 锁 ， 并 进一步 读 取 数据 。 如 采 当 前 对 象 正 在 被 修改 ， 则 读 
锁 的 申请 可 能 导致 线程 挂 起 。 


瑟 入 的 情况 可 以 参考 第 5 行 定 义 的 move0 〇 0 函数。 使 用 writeLock() 函 
数 可 以 申请 写 锁 。 这 里 的 含义 和 读 写 锁 是 类 似 的 。 


在 退出 临界 区 时 ， 不 要 雯 记 释 放 写 锁 (第 11 行 ) 或 者 读 锁 (第 24 
ITS 


可 以 看 到 ，StampedLock 通 过 引入 乐观 读 来 增加 系统 的 并 行 度 。 


6.6.2 ”StampedLock 的 小 陷阱 


StampedLock 内 部 实现 时 ， 使 用 类 似 于 CAS 操 作 的 死 循环 反复 尝试 
的 策略 。 在 它 挂 起 线程 时 ， 使 用 的 是 Unsafe.park() 汞 数 ， 而 parkO 函 数 
在 遇 到 线程 中 断 时 ， 会 直接 返回 (注意 ， 不 同 于 Thread.sleep()， 它 不 
会 抛 出 异常 ) 。 而 在 StampedLock 的 死 循 环 逻 辑 中 ， 没 有 处 理 有 关中 
电 的 逻辑 。 因 此 ， 这 就 会 导致 胆 塞 在 park() 上 的 线程 被 中 断后 ， 会 再 次 
进入 循环 。 而 当 退 出 条 件 得 不 到 满足 时 ， 吏 会 发 生 狐 狂 占 用 CPU 的 情 
况 。 这 一 点 值得 我 们 注意 ， 下 面 演 示 了 这 个 问题 : 


01 public class StampedLockCPUDemo { 


02 static Thread[] holdCpuThreads = new Thread[3]; 
03 static final StampedLock lock = new StampedLock(); 
04 public static void main(String[] args) throws 


InterruptedException { 


05 new Thread() { 

06 public void run() { 

07 long readLong = lock.writeLock(); 

08 LockSupport.parkNanos(600000000000L ) ; 

09 lock.unlockWrite(readLong) ) ， 

10 } 

11 }.start(); 

12 Thread.sleep(100) ; 

13 FOP ame 0 Be yy 

14 holdCpuThreads[i] = new Thread(new 


HoldCPUReadThread()); 

15 holdCpuThreads[i].start(); 
16 } 

17 Thread.sleep(10000) ; 


18 /7/ 线 程 中 断后 ， 会 占用 CPU 


19 FOR (CEN. DSO 0 era 


20 holdCpuThreads[i].interrupt(); 

21 } 

22 } 

23 

24 private static class HoldcPUReadThread implements 
Runnable { 

25 public void run() { 

26 long lockr = lock.readLock(); 

27 

System.out.println(Thread.currentThread().getName()+ " 获得 读 
Bt"); 

28 lock.unlockRead(lockr); 

29 } 


在 上 述 代 码 中 ， 首 先 开 局 线程 占用 写 锁 (第 7 行 ) ， 注 意 ， 为 了 演 
示 效 末 ， 这 里 使 写 线程 不 释放 锁 而 一 直 等 待 。 接 着 ， 开 局 3 个 读 线程 ， 
让 它们 请 求 读 锁 。 此 时 ， 由 于 写 锁 的 存在 ， 所 有 读 线程 都 会 被 最 终 挂 
起 。 


下 面 是 其 中 一 个 读 线程 在 挂 起 时 的 信息 : 


"Thread-2" #10 prio=5 os_prio=0  tid=0x14b1d800  nid=0xafc 
waiting on condition [0x153ef000 | 
java.lang.Thread.State: WAITING (parking) 


at sun.misc.Unsafe.park(Native Method) 
- parking to wait for <O0x046b54c8> (a 

java.util.concurrent.locks.StampedLock ) 

at 
java.util.concurrent.locks.StampedLock.acquireRead(StampedLock. 
java:1215) 

at 
java.util.concurrent.locks.StampedLock.readLock(StampedLock.jav 
a:428) 

at 
geym.conc.ch6.stamped.StampedLockCPUDemo$HoldCPUReadThread. run 
(StampedLockCPUDemo. java:35) 


at java.lang.Thread.run(Thread.java:745) 


可 以 看 到 ， 这 个 线程 因为 park0 的 操作 而 进入 了 等 竺 状态 ， 这 种 情 
况 是 正常 的 。 


而 在 10 秒 以 后 (代码 第 17 行 执行 了 10 秒 等 待 ，， 系 统 中 断 了 这 3 个 
读 线 程 ， 之 后 ， 你 就 会 发 现 ， 你 的 CPU 占用 率 极 有 可 能 会 邦 升 。 这 是 
因为 中 断 导 致 park() 了 范 数 返回 ， 使 线程 再 次 进入 运行 状态 ， 下 面 是 同一 
个 线程 在 中 断后 的 信息 : 


"Thread-2" #10 prio=5 os_prio=0  tid=0x14b1d800 nid=0xafc 
runnable [0x153ef000 | 
java.lang.Thread.State: RUNNABLE 
at sun.misc.Unsafe.park(Native Method) 
- parking to wait for <O0x046b54c8> (a 


java.util.concurrent.locks.StampedLock ) 


at 
java.util.concurrent.locks.StampedLock.acquireRead(StampedLock. 
java:1215) 

at 
java.util.concurrent.locks.StampedLock.readLock(StampedLock.jav 
a:428) 

at 
geym.conc.ch6.stamped.StampedLockCPUDemo$HoldCPUReadThread. run 
(StampedLockCPUDemo. java:35) 


at java.lang.Thread.run(Thread. java: 745) 


此 时 ， 这 个 线程 的 状态 是 RUNNABLE， 这 是 我 们 不 愿意 看 到 的 。 
它 会 一 直人 存在 并 耗 尽 CPU 资源 ， 直 到 目 己 抢占 到 了 锁 。 


6.6.3 “有关 StampedLock 的 实现 思想 


StampedLock 的 内 部 实现 是 基于 CLH 锁 的 。CLH 锁 是 一 种 自 旋 
锁 ， 它 保证 没有 饥 狐 发 生 ， 并 且 可 以 保证 FIFO (First-In-First-Out) 的 
服务 顺序 。 


CLH 锁 的 基本 思想 如 下 : 锁 维 护 一 个 等 待 线程 队列 ， 所 有 申请 
锁 ， 但 是 没有 成 功 的 线程 都 记录 在 这 个 队列 中 。 每 一 个 节点 (一 个 节 
点 代表 一 个 线程 ) ， 保 存 一 个 标记 位 (locked) ， 用 于 判断 当前 线程 
ee CAB ° 


当 一 个 线程 试图 获得 锁 时 ， 取 得 当前 等 竺 队列 的 尾部 和 点 作为 其 
前 序 节 点 ， 并 使 用 类 似 如 下 代码 判断 前 序 世 点 是 否 已 经 成 功 释 放 锁 : 


while (pred.locked) { 
t 


ARAIY T (pred) 没有 释放 锁 ， 则 表示 当前 线程 还 不 能 继续 
执行 ， 因 此 会 目 旋 等 待 。 


反之 ， 如 果 前 序 线程 已 经 释放 锁 ， 则 当前 线程 可 以 继续 执行 。 


释放 锁 时 ， 也 遵循 这 个 逻辑 ， 自身 节点 的 locked 位 置 标 
记 为 false， 那 么 后 续 等 得 的 线程 束 能 继续 执行 了 。 


如 图 6.4 所 示 ， 显 示 了 CLH 队 列 锁 的 基本 思想 。 
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图 6-4 ”CLH 队 列 锁 


StampedLock 正 是 基于 这 种 思想 ， 但 是 实现 上 更 为 复 
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在 StampedLock 内 部 ， 会 维护 一 个 等 待 链表 队列 : 


01 /** Wait nodes, */ 

02 static final class WNode { 
03 volatile WNode prev; 
04 volatile WNode next; 


05 volatile WNode cowait; // È BER 


06 volatile Thread thread; // 当 可 能 被 暂停 时 非 空 


07 volatile int status; // ©, WAITING, or CANCELLED 
08 final int mode; // RMODE or WMODE 

09 WNode(int m, WNode p) { mode = m; prev = p; } 

10 } 

11 


12 /** CLH 队列 头 部 */ 
13 private transient volatile WNode whead; 


14 /** CLH Bee */ 


15 private transient volatile WNode wtail; 


上 述 代 码 中 ，WNode 为 链表 的 基本 元 素 ， 每 一 个 WNode 表 示 一 个 
等 待 线程 。 字 段 whead 和 wtail 分 别 指 向 等 待 链 表 的 头 部 和 尾部 。 


另外 一 个 重要 的 字段 为 state: 
private transient volatile long state; 


字段 state 表 示 当 前 锁 的 状态 。 它 是 一 个 long 型 ， 有 64 人 位， 其中， 
倒数 第 8 位 表示 写 锁 状态 ， 如 果 该 位 为 1， 表 示 当 前 由 写 锁 占 用 。 


对 于 一 次 乐观 读 的 操作 ， 它 会 执行 如 下 操作 : 


public long tryOptimisticRead() { 
long s; 


return (((s = state) & WBIT) == OL) ? (s & SBITS) : OL; 


一 次 成 功 的 乐观 读 必须 保证 当前 锁 没 有 写 锁 占 用 。 其 中 WBIT 用 
来 获取 写 锁 状态 位 ， 值 为 0x80。 如 果 成 功 ， 则 返回 当前 state 的 值 (AR 
尾 7 位 清 零 ， 末 尾 7 位 表示 当前 正在 读 取 的 线程 数量 ) 。 


如 采 在 乐观 读 后 ， 有 线程 申请 了 写 锁 ， 那 么 state 的 状态 束 会 改 


1 public long writeLock() { 


2 long s, next; // bypass acquirewrite in fully unlocked 
case only 

3 return ((((s = state) & ABITS) == OL && 

4 U.compareAndSwapLong(this, STATE, s, next = S + 
WBIT)) ? 

5 next : acquireWrite(false, OL)); 

6 } 


上 述 代 码 中 第 4 行 ， 设 置 写 锁 位 为 1 (通过 加 上 WBIT 
(0x80) ) 。 这 样 ， 束 会 改变 state 的 取 值 。 那 么 在 乐观 锁 确认 
(validate) 时 ， 就 会 发 现 这 个 改动 ， 而 导致 乐观 锁 失 效 。 


public boolean validate(long stamp) { 
U.loadFence()j; 


return (stamp & SBITS) == (state & SBITS); 


上 述 validate0 函 数 比 较 当 前 stamp 和 发 生 乐 观 锁 时 取得 的 stamp， 
如 宁 不 一 致 ， 则 宣告 乐观 锁 失 败 。 


乐观 锁 失 败 后 ， 则 可 以 提升 锁 级 别 ， 使 用 悲观 读 锁 。 


1 public long readLock() { 
2 long s = state, next; // bypass acquireRead on common 


uncontended case 


3 return ((whead == wtail && (s & ABITS) < RFULL && 

4 U.compareAndSwapLong(this, STATE, s, next = S + 
RUNIT)) ? 

5 next : acquireRead(false, OL)); 

6 } 


悲观 读 会 党 试 设 置 state 状 态 (F447) ， 它 会 将 state 加 1 〈 前 提 是 
读 线程 数量 没有 液 出 ， 对 于 读 线程 数量 洪 出 的 情况 ， 会 使 用 辅助 的 
readerOverflow 进 行 统计 ， 我 们 在 这 里 不 做 过 于 烦琐 的 讨论 ) ， 用 于 统 
计 读 线程 的 数量 。 如 果 失 败 ， 则 进入 acquireRead0) 二 次 尝试 锁 获取 。 


在 acquireRead0 中 ， 线 程 会 在 不 同 条 件 下 进行 若干 次 目 旋 ， 试 
通过 CAS 操 作 获得 锁 。 如 果 目 旋 宣 告 失败 ， 则 会 局 用 CLH 队 列 ， 将 目 
己 加 到 队列 中 。 之 后 再 进行 目 旋 ， 如 果 发 现 自己 成 功 获 得 了 读 锁 ， 则 
会 进一步 把 上 自己 cowait 队 列 中 的 读 线程 全 部 激活 (EM Unsafe.unpark() 
方法 ) 。 如 果 最 终 依然 无 法 成 功 获得 读 锁 ， 则 会 使 用 Unsafe.park(0) 方 法 
挂 起 当前 线程 。 


方法 acquireWrite() 和 acquireRead() 也 非常 类 似 ， 也 是 通过 自 旋 尝 
试 、 加 入 等 待 队 列 、 直 至 最 终 Unsafe.park() 挂 起 线程 的 逻辑 进行 的 。 释 
放 锁 时 与 加 锁 动 作 相 反 ， 以 unlockWrite() 为 例 : 


1 public void unlockwrite(long stamp) { 
2 WNode h; 
3 if (state != stamp || (stamp & WBIT) == OL) 


4 throw new IllegalMonitorStateException(); 

5 state = (stamp += WBIT) == OL ? ORIGIN : stamp; 
6 if ((h = whead) != null && h.status != 0) 

7 release(h); 

8 } 


上 述 代码 第 5 行 ， 将 写 标 记 位 清 零 ， 如 来 state 发 生 洲 出 ， 则 退回 到 
初始 值 。 


接着 ， 如 果 等 竺 队列 不 为 空 ， 则 从 等 待 队 列 中 激活 一 个 线程 ( 绝 
大 部 分 情况 下 是 第 1 个 等 待 线程 ) 继续 执行 (第 7 行 ) 。 


6.7 原子 类 的 增强 


在 之 前 的 划 广 中 已 经 提 到 了 原子 类 的 使 用 ， 无 锁 的 原子 类 操作 使 
用 系统 的 CAS 指 令 ， 有 着 远 远 超越 锁 的 性 能 。 那 是 否 有 可 能 在 性 能 
更 上 一 层 楼 呢 ? 答案 是 肯定 的 。 在 Java 8 中 引入 了 LongAdder 类 ， 这 个 
类 也 在 java.util.concurrent.atomic 包 下 ， 因 此 ， 可 以 推测 ， 它 也 是 使 用 
了 CAS 指 令 。 


6.7.1 更 快 的 原子 类 : LongAdder 


大 家 对 AtomicInteger 的 基本 实现 机 制 应 该 比较 了 解 。 它 们 都 是 在 
一 个 死 循 环 内 ， 不 断 符 试 修 改 目标 值 ， 直 到 修改 成 功 。 如 采 竞 争 不 油 
烈 ， 那 么 修改 成 功 的 概率 殊 很 高 ， 否 则 ， 修 改 失 败 的 概率 就 很 高 。 在 
大 量 修改 失败 时 ， 这 些 原 子 操 作 融 会 进行 多 次 循环 答 试 ， 因 此 性 能 束 


会 受到 影响 。 


那么 当 竞争 激烈 的 时 候 ， 我 们 应 该 如 何 进一步 提高 系统 的 性 能 
WE? 一 种 基本 方案 就 是 可 以 使 用 热点 分 离 ， 将 竞争 的 数据 进行 分 解 ， 
基于 这 个 思路 ， 大 家 应 该 可 以 想到 一 种 对 传统 AtomicInteger 等 原子 类 
的 改进 方法 。 虽 然 在 CAS 操 作 中 没有 锁 ， 但 是 像 减 小 锁 粒 度 这 种 分 离 
热点 的 思想 依然 可 以 使 用 。 一 种 可 行 的 方案 就 是 仿造 
ConcurrentHashMap ， 将 热点 数据 分 离 。 比 如 ， 可 以 将 AtomicInteger 的 
内 部 核心 数据 value 分 离 成 一 个 数组 ， 每 个 线程 访问 时 ， 通 过 哈 希 等 售 
法 映射 到 其 中 一 个 数字 进行 计数 ， 而 最 终 的 计数 结果 ， 则 为 这 个 数组 
的 求 和 累加 ， 如 图 6.5 所 示 ， 显 示 了 这 种 优化 思路 。 其 中 ， 热 点 数据 


value 被 分 离 成 多 个 单元 cell， 每 个 cell 独 上 自 维护 内 部 的 值 ， 当 前 对 象 的 
实际 值 由 所 有 的 cell 累 计 合成 ， 这 样 ， 热 点 就 进行 了 有 效 的 分 离 ， 提 高 
了 并 行 度 。LongAdder 正 是 使 用 了 这 种 思想 。 
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图 6.5 原子 类 的 优化 思路 


在 实际 的 操作 中 ，LongAdder 并 不 会 一 开始 整 动 用 数组 进行 处 
理 ， 而 十 将 所 有 数据 部 和 完 记 录 在 一 个 称 为 base 的 变量 中 。 如 来 在 多 线 
程 条 件 下 ， 大 家 修改 base 部 没有 冲突 ， 那 么 也 没有 必要 扩展 为 cell 数 
组 。 但 是 ， 一 旦 base 修 改 发 生 冲 突 ， 束 会 初始 化 cell 数 组 ， 使 用 新 的 集 
略 。 如 果 使 用 cel 数 组 更 新 后 ， 发 现在 某 一 个 ceall 上 的 更 新 依然 发 生 冲 
突 ， 那 么 系统 就 会 尝试 创建 新 的 cell， 或 者 将 cell 的 数量 加 倍 ， 以 减少 
冲突 的 可 能 。 


下 面 我们 简单 分 析 一 下 increment( 方 法 (该 方法 会 将 LongAdder 自 
增 1) 的 内 部 实现 : 


01 public void increment() { 
02 add(1iL); 

03 } 

04 public void add(long x) { 


05 Cell[] as; long b, v; int m; Cell a; 


06 if ((as = cells) != null || !casBase(b = base, b + x)) { 
07 boolean uncontended = true; 

08 if (as == null || (m = as.length - 1) < © || 

09 (a = as[getProbe() & m]) == null || 

10 !(uncontended = a.cas(v = a.value, v + x))) 

11 longAccumulate(x, null, uncontended); 

12 } 

13 } 


它 的 核心 是 第 4 行 的 add0 方 法 。 最 开始 cells 为 null， 因 此 数据 会 向 
base 增 加 (第 6 行 )。 但 是 如 果 对 base 的 操作 冲突 ， 则 会 进入 第 7 行 ， 
并 设置 冲突 标记 uncontended 为 tue。 接 着 ， 如 果 判 断 cells 数 组 不 可 用 ， 
或 者 当前 线程 对 应 的 cell 为 null， 则 直接 进入 longAccumulate() 方 法 。 否 
则 会 尝试 使 用 CAS 方 法 更 新 对 应 的 cell 数 据 ， 如 果 成 功 ， 则 退出 ， 失 败 
则 进入 longAccumulate() 方 法 。 


由 于 longAccumulate() 方 法 比较 复杂 ， 限 于 篇 幅 ， 这 里 不 再 展开 讨 
论 ， 其 大 致 内 容 是 根据 需要 创建 新 的 cell 或 者 对 cell 数 组 进行 扩容 ， 以 
减少 冲突 。 


下 面 ， 让 我 们 简单 地 对 LongAddr、 原 子 类 以 及 同步 锁 进行 性 能 测 
试 。 测 试 方法 是 使 用 多 个 线程 对 同一 个 整数 进行 素 加 ， 观 察 使 用 3 种 不 
同方 法 时 所 消耗 的 时 间 。 


目 先 ， 我 们 定义 一 些 辅助 变量 : 


private static final int MAX_THREADS = 3; // 线 程 
数 


private static final int TASK_COUNT = 3; INES 
数 

private static final int TARGET_COUNT = 10000000; // 目 标 
private AtomicLong acount =new AtomicLong(®OL); // 无 锁 
的 原子 操作 


private LongAdder lacount=new LongAdder(); 


private long count=0; 


static CountDownLatch cdlsync=new CountDownLatch(TASK_COUNT); 
static CountDownLatch cdlatomic=new CountDownLatch(TASK_COUNT) ; 


static CountDownLatch cdladdr=new CountDownLatch(TASK_COUNT) ; 


上 述 代 码 中 ， 指 定 了 测试 线程 数量 、 目 标 总 数 以 及 3 个 初始 值 为 0 
的 整 型 变量 acount、lacount 和 count。 它 们 分 别 表示 使 用 AtomicLong、 
LongAdder 和 锁 进 行 同步 时 的 操作 对 象 。 


下 面 是 使 用 同步 锁 时 的 测试 代码 : 


@1 protected synchronized long inc(){ // 有 锁 
的 加 法 

02 return ++count; 

03 } 

04 


05 protected synchronized long getCount(){ // 有 锁 


的 操作 


06 
vat 
08 
09 


return count; 


10 public class SyncThread implements Runnable{ 


11 
12 
13 
14 
15 
16 
Ly) 
18 
19 
20 
2i 


protected String name; 

protected long starttime; 

LongAdderDemo out; 

public SyncThread(LongAdderDemo o, long starttime) { 
out=o; 
this.starttime=starttime; 

上 

@Override 

public void run() { 
long v=out.getCount(); 
while(v< TARGET_COUNT ) { 


达 目 标 值 前 ， 不 停 循环 


22 
23 
24 
25 


v=out.inc(); 


J 


long endtime=System.currentTimeMillis(); 


// 在 到 


System.out.println("SyncThread spend:"+(endtime- 


starttime)+"ms"+" V="+V); 


26 
27 


29 


cdlsync.countDown( ); 


30 public void testSync() throws InterruptedException{ 
31 ExecutorService 


exe=Executors.newFixedThreadPool(MAX_THREADS) ; 


32 long starttime=System.currentTimeMillis(); 

33 SyncThread sync=new SyncThread(this, starttime); 

34 for(int 1=0;1<TASK_COUNT;1i++) { 

35 exe.submit(sync); // 提 区 
线程 开始 计算 

36 } 

37 cdlsync.await(); 

38 exe. shutdown(); 

39 } 


上 述 代 码 第 10 行 ， 定 义 线 程 SyncThread， 它 使 用 加 锁 方 式 增 加 
count 的 值 。 在 第 30 行 定义 的 testSync() 方 法 中 ， 使 用 线程 池 控 制 多 线程 
进行 票 加 操作 。 


使 用 类 似 的 方法 实现 原子 类 素 加 计时 统计 : 


01 public class AtomicThread implements Runnable{ 


02 protected String name; 

03 protected long starttime; 

04 public AtomicThread(long starttime) { 

05 this.starttime=starttime; 

06 } 

07 @Override 

08 public void run() { // 


在 到 达 目 标 值 前 ， 不 停 循 环 


09 long v=acount.get(); 


10 while(v< TARGET_COUNT ) { 

11 v=acount.incrementAndGet(); // 
无 锁 的 加 法 

12 } 

LE long endtime=System.currentTimeMillis(); 

14 System.out.println("AtomicThread spend:"+(endtime- 


starttime)+"ms"+" v="+v); 
15 cdlatomic .countDown(); 


16 } 


19 public void testAtomic() throws InterruptedException{ 
20 ExecutorService 


exe=Executors .newFixedThreadPool(MAX_THREADS); 


21 long starttime=System.currentTimeMillis(); 

22 AtomicThread atomic=new AtomicThread(starttime); 

23 for(int i=0;i<TASK_COUNT;i++){ 

24 exe.submit(atomic); TH 
提交 线程 开始 计算 

25 } 

26 cdlatomic.await(); 

27 exe. shutdown(); 

28 } 


同 理 ， 以 下 代码 使 用 LongAddr 实 现 类 似 的 功能 : 


01 public class LongAddrThread implements Runnable{ 


02 protected String name; 

03 protected long starttime; 

04 public LongAddrThread(long starttime) { 

05 this.starttime=starttime; 

06 } 

07 @Override 

08 public void run() { 

09 long v=lacount.sum(); 

10 while(v< TARGET_COUNT ) { 

11 lacount.increment(); 

12 v=lacount.sum(); 

13 } 

14 long endtime=System.currentTimeMillis(); 
15 System.out.printin("LongAdder spend:"+(endtime- 


starttime)+"ms"+" v="+v); 
16 cdladdr.countDown(); 


17 } 


20 public void testAtomicLong() throws InterruptedException{ 
21 ExecutorService 


exe=Executors.newFixedThreadPool(MAX_THREADS) ; 


22 long starttime=System.currentTimeMillis(); 
23 LongAddrThread atomic=new LongAddrThread(starttime) ; 
24 for(int i=0;i<TASK_COUNT; i++) { 


25 exe.submit(atomic); // 


提交 线程 开始 计算 


26 } 

27 cdladdr.await(); 
28 exe. shutdown( ); 
29 } 


注意 ， 由 于 LongAddr 中 ， 将 单个 数值 分 解 为 多 个 不 同 的 段 。 
此 ， 在 进行 标 加 后 ， 上 述 代 码 中 第 11 行 的 ncrementO 函 数 并 不 能 返回 
当前 的 数值 。 要 取得 当前 的 实际 值 ， 需 要 使 用 第 12 行 的 sum() 芳 数 重 新 
计算 。 这 个 计算 是 需要 有 额外 的 成 本 的 ， 但 即使 加 上 这 个 额外 成 本 ， 
LongAddr 的 表现 还 是 比 AtomicLong 要 好 。 


执行 这 些 代 码 ， 殊 可 以 得 到 锁 、 原 子 类 和 LongAddr 三 者 的 性 能 比 
较 数 据 ， 如 下 所 示 : 


SyncThread spend:1784ms v=10000002 
SyncThread spend:1784ms v=10000000 
SyncThread spend:1784ms v=10000001 
AtomicThread spend:695ms v=10000001 
AtomicThread spend:695ms v=10000000 
AtomicThread spend:695ms v=10000002 
LongAdder spend:227ms v=10000002 
LongAdder spend:227ms v=10000002 
LongAdder spend:227ms v=10000002 


可 以 看 到 ， 就 计数 性 能 而 言 ，LongAdder 已 经 超越 了 普通 的 原子 
操作 了 。 其 中 ， 锁 操作 耗 时 约 1784ms， 普 通 原 子 操作 耗 时 约 695ms， 
而 LongAddr 仅 需要 227ms 左 右 。 


LongAddr 的 另外 一 个 优化 手段 是 避免 了 伪 共享 。 大 家 可 以 多 回顾 
一 下 第 5 草 中 有 头 伪 共 吾 的 问题 。 但 是 ， 需 要 注意 的 是 ，LongAddr 中 
并 不 是 直接 使 用 padding 这 种 看 起 来 比较 碍 眼 的 做 法 ， 而 是 引入 了 一 种 
新 的 注释 “@sun.misc.Contended”。 


对 于 LongAddr 中 的 每 一 个 Cell， 它 的 定义 如 下 所 示 : 


@sun.misc.Contended 
static final class Cell { 

volatile long value; 

Cell(long x) { value = x; } 

final boolean cas(long cmp, long val) { 

return UNSAFE.compareAndSwapLong(this, valueOffset, 

cmp, val); 

Í 
省 略 其 他 不 必要 的 信息 


可 以 看 到 ， 在 上 述 代 码 第 1 行 申 明了 Cell 类 为 sun.misc.Contended ° 
这 将 会 使 得 Java 虚 拟 机 目 动 为 Cell 解 决 伪 共 至 问题 。 


当然 ， 在 我 们 上 自己 的 代码 中 也 可 以 使 用 sun.misc.Contended 来 解决 
伪 共 享 问题 ， 但 是 需要 额外 使 用 虚拟 机 参数 -XX:-RestrictContended，， 
否则 ， 这 个 注释 将 被 忽略 。 


大 家 应 该 还 记得 第 5 章 中 有 关 伪 共享 的 案例 吧 ! 限于 篇 幅 ， 这 里 不 
再 贴 出 完整 代码 ， 只 给 出 关键 部 分 的 改动 。 我 们 将 VolatileLong 修 改 如 
T 


@sun.misc.Contended 
public final static class VolatileLong { 


public volatile long value = OL; 


在 这 里 ， 我 们 去 除了 那些 看 起 来 不 太 雅 观 的 padding， 同 时 增加 了 
sun.misc.Contended 申 明 ， 这 个 吏 告 诉 虚拟 机 我 们 硕 望 在 这 个 类 上 解决 
伪 共 享 问题 。 然 后 ， 我 们 就 可 以 测试 这 段 代 码 了 。 当 然 了 ， 千 万 不 要 
态 记 指定 虚拟 机 参数 -XX:-RestrictContended， 否 则 ， 你 的 这 个 优化 将 
被 无 视 。 


跑 一 下 优化 后 的 程序 ， 是 不 是 比 传统 的 方式 快 很 多 呢 ? 


6.7.2 ”LongAdder 的 功能 增强 版 : 


LongAccumulator 


LongAccumulator 是 LongAdder 的 杀 兄 第， 它们 有 公共 的 父 类 
Striped64。 因 此 ，LongAccumulator 内 部 的 优化 方式 和 LongAdder 是 一 
样 的 。 它 们 都 将 一 个 long 型 整数 进行 分 割 ， 存 储 在 不 同 的 变量 中 ， 以 
防止 多 线程 苋 争 。 两 者 的 主要 逻辑 是 类 似 的 ， 但 是 LongAccumulator 是 
LongAdder 的 功能 扩展 ， 对 于 LongAdder 来 说 ， 它 只 是 每 次 对 给 定 的 整 
数 执行 一 次 加 法 ， 而 LongAccumulator 则 可 以 实现 任意 函数 操作 © 


可 以 使 用 下 面 的 构造 函数 创建 一 个 LongAccumulator 实 例 : 


public LongAccumulator (LongBinaryOperator 


accumulatorFunction, long identity) 


第 1 个 参数 accumulatorFunction 就 是 需要 执行 的 二 元 函数 (接收 两 
个 long 形 参数 并 返回 long) ， 第 2 个 参数 是 初始 值 。 


下 面 这 个 例子 展示 了 LongAccumulator 的 使 用 ， 它 将 通过 多 线程 访 
问 知 干 个 整数 ， 并 返回 遇 到 的 最 大 的 那个 数 子 。 


01 public static void main(String[] args) throws Exception { 
02 LongAccumulator accumulator = new 


LongAccumulator(Long::max, Long.MIN_VALUE); 


03 Thread[] ts = new Thread[1000]; 

04 

05 ror (aime i = ©; OOO iim) {f 

06 ts[i] = new Thread(() -> { 

07 Random random = new Random(); 
08 long value = random.nextLong(); 
09 accumulator .accumulate(value) ; 
10 }); 

11 ts[i].start(); 

12 } 

13 for (int ił = 0; 1 < 1000; i++) { 

14 ts[i].join(); 

15 } 

16 System.out.println(accumulator .longValue()); 
iy p 


上 述 代 码 第 2 行 ， 构 造 了 LongAccumulator 实 例 。 因 为 我 们 要 过 小 
最 大 值 ， 因 此 传 入 Long::max 芳 数 句 顶 。 当 有 数据 通过 accumulate() 方 
法 传 入 LongAccumulator 后 (第 9 行 ) ，LongAccumulator 会 通过 


人 (很 可 能 是 cell 数 组 内 ， 也 可 能 
是 base) 。 在 代码 第 16 行 ， 通 过 longValue0 函 数 对 所 有 的 cell 进 行 
Long::max 操 作 ， 得 到 最 大 值 。 
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第 7 章 ”使 用 Akka 构 建 高 并 发 程序 


我 们 知道 ， 写 出 一 个 正确 的 、 高 性 能 并 且 可 扩展 的 并 发 程序 是 相 
当 困 难 的 ， 那 么 是 否 有 一 个 好 的 框架 可 以 帮助 我 们 轻松 构建 这 么 一 个 
应 用 呢 ? 答案 是 肯定 的 ， 那 就 是 Akka。Akka 是 一 蒜 遵 循 Aapche 2 许可 
的 开源 人 员 ， 这 意味 着 你 可 以 无 偿 并 且 几 乎 没有 限制 地 使 用 它 ， 包 括 
将 它 应 用 于 商业 环境 中 。 


Akka 是 用 Scala 创 建 的 ， 但 由 于 Scala 和 和 Java 一样， 都 是 Java 虚 拟 机 
上 的 语言 ， 本 质 上 说 ， 两 者 并 没有 什么 不 同 ， 因 此 ， 我 们 也 可 以 在 
Java 中 使 用 Akka。 考 虑 到 Java 开 发 人 员 的 数量 远 远 高 于 Scala， 为 了 方 
便 大 众 ， 在 这 里 ， 我 将 全 程 使 用 Java 来 作为 Akka 的 宿主 语言 (本 书 使 
用 Akka 2.11-2.3.7 作 为 演示 ) 。 但 我 并 不 打算 在 这 里 把 对 Akka 的 介绍 
写成 一 个 Akka 使 用 手册 ， 因 此 ， 不 会 对 Akka 进 行 全 方位 完整 的 API 介 
绍 。 只 是 希望 在 这 里 对 Akka 的 主要 功能 进行 简单 的 描述 ， 帮 助 大 家 尽 
快 理解 Akka 的 基本 思想 。 


那么 使 用 Akka 能 够 给 我 们 市 来 什么 好 处 呢 ? 


目 先 Akka 提 供 了 一 种 称 为 Actor 的 并 发 模型 ， 其 粒度 比 线程 更 小 ， 
这 意味 着 你 可 以 在 系统 中 启用 极其 大 量 的 Actor 。 


其 次 ，Akka 中 提供 了 一 套 容错 机 制 ， 人 允许 在 Actor 出 现 异 常 时 进行 
一 些 恢复 或 者 重 置 操 作 。 


最 后 ， 通 过 Akka 不 仅 可 以 在 单机 上 构建 高 并 发 程序 ， 也 可 以 在 网 
络 中 构建 分 布 式 程序 ， 并 提供 位 置 透 明 的 Actor 定 位 服务 。 


下 面 束 让 我 们 正式 开局 Akka 之 旅 吧 ! 


7.1 SrtA: Actor 


对 于 并 发 程序 来 说 ， 线 程 始终 作为 并 发 程序 的 基本 执行 单元 。 但 
在 Akka 中 ， 你 可 以 完全 忘记 线程 了 。 当 你 使 用 Akka 时 ， 你 束 有 一 个 全 
渐 的 执行 单元 Actor。Actor 是 什么 呢 ? 


简单 来 说 ， 你 可 以 把 Actor 比 喻 成 一 个 人 。 多 个 人 之 间 可 以 使 用 语 
于 进行 交流 。 比 如 ， 老师 问 同学 5 乘 以 5 是 多 少 呀 ? 同学 听 到 问题 后 ， 
想 了 想 ， 回 答 说 是 25。Actor 之 间 的 通信 方式 和 上 述 对 话 形式 几乎 是 一 
模 一 样 的 。 


传统 Java 并 行程 序 ， 还 是 完全 基于 面 回 对 象 的 方法 。 我 们 还 是 通 
过 对 象 的 方法 调用 进行 信息 的 传递 。 这 时 ， 如 采 对 象 的 方法 会 修改 对 
象 本 喘 的 状态 ， 那 么 在 多 线程 情况 下 ， 束 有 可 能 出 现 对 象 状 态 的 不 一 
致 ， 所 以 我 们 必须 对 这 类 方法 调用 进行 同步 。 当 然 ， 同 步 往往 就 是 以 
牺牲 性 能 为 代价 的 。 


在 Actor 模 型 中 ， 我 们 失去 了 对 象 的 方法 调用 ， 我 们 并 不 是 通过 调 
用 Actor 对 象 的 某 一 个 方法 来 告诉 Actor 你 需要 做 什么 ， 而 是 给 Actor 发 
送 一 条 消息 。 当 一 个 Actor 收 到 消息 后 ， 它 有 可 能 会 根据 消 筷 的 内 容 做 
出 某 些 行为 ， 包 括 更 改 自 号 状态。 但是， 在 这 种 情况 下 ， 这 个 状态 的 
更 改 是 Actor 上 自己 进行 的 ， 并 不 是 由 外 界 被 迫 进 行 的 。 


7.2 AkkaZHello World 


在 了 解 了 Actor 的 基本 行为 模式 后 ， 我 们 通过 人 简单 的 Hello World 程 
序 来 进一步 了 解 一 下 Akka 的 开发 。 


首先 让 我 们 看 一 下 ， 第 1 个 Actor 的 实现 : 


01 public class Greeter extends UntypedActor { 
02 public static enum Msg { 

03 GREET, DONE; 

04 } 

05 

06 @Override 


07 public void onReceive(Object msg) { 


08 if (msg == Msg.GREET) { 

09 System.out.printin( "Hello World!"); 

10 getSender().tell(Msg.DONE, getSelf()); 
11 } else 

12 unhandled(msg); 

thee J 

14 } 


上 述 代 码 中 ， 定 义 了 一 个 欢迎 者 (Greeter) Actor， 它 继承 上 自 
UntypedActor ( 它 自然 就 是 Akka 中 的 核心 成 员 了 ) 。UntypedActor 就 
是 我 们 所 说 的 Actor， 之 所 以 这 里 强调 是 无 类 型 的 ， 那 是 因为 在 Akka 
中 ， 还 文 持 一 种 有 类 型 的 Actor。 有 类 型 的 Actor 可 以 使 用 系统 中 的 其 


他 类 型 构造 ， 可 以 缓解 Java 单 继承 的 问题 。 因 为 你 在 继承 了 
UntypedActor 后 ， 中 个 再 继承 系统 中 的 其 他 类 了 。 如 采 你 一 定 想 这 
么 做 ， 那 么 束 只 能 选择 有 类 型 的 Actor。 人 否则 ，UntypedActor 应 该 就 是 
你 的 首选 


在 这 里 ， 代 码 第 2~4 行 ， 定 义 了 消息 类 型 。 这 里 只 有 两 种 类 型 ， 
欢迎 (GREET) 以 及 完成 (DONE) pie ee ceased 时 ， 
就 会 在 控制 台 打印 “Hello World”， 并 且 向 消息 发 送 方 发 送 DONE 信 息 

(第 10 行 ) 。 


与 Greeter 交 流 的 另外 一 个 Actor 是 HellowWorld， 它 的 实现 如 下 : 


01 public class HelloWorld extends UntypedActor { 


02 ActorRef greeter; 

03 

04 @Override 

05 public void preStart() { 

06 greeter = 


getContext().actorOf(Props.create(Greeter.class), "greeter"); 
07 System.out.println("Greeter Actor Path:" + 


greeter.path()); 


08 greeter.tell(Greeter.Msg.GREET, getSelf()); 
09 } 

10 

14 @Override 

12 public void onReceive(Object msg) { 

13 if (msg == Greeter.Msg.DONE) { 


14 greeter.tell(Greeter.Msg.GREET, getSelf()); 


15 getContext().stop(getSelf()); 


16 } else 

17 unhandled(msg); 
18 } 

19 } 


上 述 代码 实现 了 一 个 名 为 HelloWorld 的 Actor。 第 5 行 的 preStart0 方 

法 为 Akka 的 回调 方法 ， 在 Actor 启 动 前 ， 会 被 Akka 框 架 调 用 ， 完 成 一 
些 初始 化 的 工作 。 在 这 里 ， 我 们 在 HelloWorld 中 创建 了 Greeter 的 实例 
(第 6 行 ) ， 并 且 向 它 发 送 GREET 消 息 (第 8 行 ) 。 此 时 ， 由 于 创建 
Greeter 时 使 用 的 是 HelloWorld 的 上 下 文 ， 因 此， 它 属于 HelloWorld 的 子 
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此 ，Greeter 会 前 后 收 到 两 条 GREET 消 息 ， 会 打印 两 次 “Hello 
World” ° 


最 后 ， 让 我 们 看 一 下 主 函 数 main(0): 


1 public class HelloMainSimple { 

2 public static void main(String[] args) { 

3 Actorsystem system = 
ActorSystem.create("Hello", ConfigFactory.load("samplehello.conf 
ee 

4 ActorRef a = 


system.actorOf(Props.create(HellowWorld.class),"helloWorld"); 


5 System.out.println("Helloworld Actor Path:" + 
a.path()); 

6 } 

v3 


程序 第 3 行 ， 创 建 了 ActorSystem ， 表 示 管 理 和 维护 Actor 的 系统 。 
一 般 来 说 ， 一 个 应 用 程序 只 需 -个 ActorSystem Wi i FA T ° 
ActorSystem.create() 的 第 1 个 参数 “Hello” 为 系统 名 称 ， 第 2 个 参数 为 配 
置 文件 。 


第 4 行 通过 ActorSystem 创 建 一 个 顶级 的 Actor (HelloWorld) ° 


配置 文件 samplehello.conf 的 内 容 如 下 : 


akka { 
loglevel = INFO 


在 这 里 ， 只 十 简单 地 配置 了 一 下 日 志 级 别 为 INFO 。 
执行 上 述 代码 ， 可 以 看 到 以 下 输出 : 


1 HelloWorld Actor Path:akka://Hello/user/helloworld 

2 Greeter Actor Path:akka://Hello/user/helloworld/greeter 

3 Hello World! 

4 Hello World! 

5 [INFO] [05/13/2015 21:15:01.299] [Hello-akka.actor.default- 


dispatcher -2] 


[akka://Hello/user/helloworld] Message 
[geym.akka.demo.hello.Greeter$Msg] from 

Actor [akka: //Hello/user/helloworld/greeter#-1698722495] to 
Actor [akka: //Hello/user/helloWwor 1d#-1915075849 | was not 
delivered. [1] dead letters 

encountered. This logging can be turned off or adjusted with 
configuration settings 

‘akka.log-dead-letters' and 'akka. log-dead-letters-during- 


shutdown' . 


第 1 行 打印 了 Helloworld Actor 的 路 径 。 它 是 系统 内 第 1 个 被 创建 的 
Actor 。 它 的 路 径 为 : akka:/Hello/userhellowWorld。 其 中 第 1 个 Hello 表 
示 ActorSystem 的 系统 名 ， 可 以 看 一 下 我 们 构造 这 ActorSystem 时 ， 传 入 
的 第 1 个 参数 束 是 Hello。 接 着 user 表 示 用 户 Actor。 所 有 的 用 户 Actor 都 
会 挂 载 在 user 这 个 路 径 下 。 第 3 个 hellowWorld 就 是 这 个 Actor 的 名字。 


同 理 ， 第 2 个 Greeter Actor 的 路 径 结构 和 Helloworld 是 完全 一 臻 
的 。 输 出 的 第 3、4 行 显示 了 Greeter 打 印 的 两 条 信息 。 第 5 行 表示 系统 过 
到 了 一 条 消息 投递 失败 ， 失 败 的 原因 是 HellowWorld 将 目 己 终 止 了 ， 导 
致 Greeter 发 送 的 信息 无 法 投递 。 


可 以 看 到 ， 当 使 用 Actor 进 行 并 行程 序 开 发 时 ， 我 们 的 关注 点 已 经 
不 在 线程 上 了 “。 实 际 上 ， 线 程 调度 已 经 被 Akka 框 淋 进 行 封装 ， 我 们 只 
需要 关注 Actor 对 象 即 可 。 而 Actor 对 象 之 间 的 交流 和 普通 的 对 象 的 函 
数 调用 有 了 明显 区 别 。 它 们 是 通过 显示 的 消 轧 发 送 来 传递 信息 的 。 


当 系统 内 有 多 个 Actor 存 在 时 ，Akka 会 自动 在 线程 池 中 选择 线程 来 
执行 我 们 的 Actor。 因 此 ， 多 个 不 同 的 Actor 有 可 能 会 被 同一 个 线程 执 


行 ， 同 时 ， 一 个 Actor 也 有 可 能 被 不 同 的 线程 执行 。 因 此 ， 一 个 值得 注 
意 的 地 方 是 : 不 要 在 一 个 Actor 中 执行 耗 时 的 代码 ， 这 样 可 能 会 导致 其 
他 Actor 的 调度 出 现 问题 。 


73 ”有 关 消 息 投 递 的 一 些 说 明 


整个 Akka 应 用 是 由 消 居 驱 动 的 。 消 恩 是 除了 Actor 之 外 最 重要 的 核 
心 组 件 。 作 为 在 并 发 程序 中 的 核心 组 件 ， 在 Actor 之 间 传 递 的 消息 应 该 
满足 不 可 变性 ， 也 束 是 不 变 模式 。 因 为 可 变 的 消 奶 无 法 高 效 的 在 并 发 
环境 中 使 用 。 理 论 上 Akka 中 的 消 恩 可 以 使 用 任何 对 象 实 例 ， 但 实际 使 
用 中 ， 强 烈 推 荐 使 用 不 可 变 的 对 象 。 一 个 典型 的 不 可 变 对 象 的 实现 如 
T 


01 public final class ImmutableMessage { 


02 private final int sequenceNumber; 

03 

04 private final List<String> values; 

05 

06 public ImmutableMessage(int sequenceNumber, List<String 


> values) { 
07 this.sequenceNumber = sequenceNumber ; 
08 this.values = Collections.unmodifiableList (new 


ArrayList <String> (values) ); 


09 } 

10 

11 public int getSequenceNumber() { 
12 return sequenceNumber ; 

13 } 


14 


15 public List<String> getValues() { 


16 return values; 


上 述 代 码 实现 了 一 个 不 可 变 的 消息 。 注 意 代 人 码 中 对 final 的 使 用 ， 
它 申 明了 当前 消息 中 的 儿 个 字段 都 是 常量 ， 在 消息 构造 完成 后 ， 就 不 
能 再 发 生 改 变 了 。 更 加 需要 注意 的 是 ， 对 于 values 字 段 ，final 关 键 字 只 
能 保证 values 引 用 的 不 可 变性 ， 并 无 法 保证 values 对 象 的 不 可 变性 。 为 
了 实现 彻底 的 不 可 变性 ， 代 码 第 8 行 构 造 了 一 个 不 可 变 的 List 对 象 。 


对 于 消 思 投递， 大 家 可 能 还 有 另外 一 个 疑问 ， 那 融 是 消息 投递 客 
苋 古 以 何 种 策略 进行 的 呢 ? 也 融 是 发 出 去 的 消 妃 一 定 会 被 对 方 接收 到 
吗 ? 如 果 接 收 不 到 会 重 发 吗 ? 有 没有 可 能 重复 接收 消息 呢 ? 


实际 上 ， 对 于 消 妃 投递 ， 我 们 可 以 有 3 种 不 同 的 策略 : 


第 1 种 ， 称 为 至 多 一 次 投递 。 在 这 种 策略 中 ， 条 消息 最 多 会 被 
投递 一 次 。 在 这 种 情况 下 ， 可 能 偶尔 会 出 现 消 息 投 递 失败， 而 导致 消 
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递 一 次 ， 直 到 成 功 为 止 。 因 此 在 一 些 偶然 的 场 含 ， 接 受 者 可 能 会 收 到 
重复 的 消 思 ， 但 不 会 发 生 消息 丢失 。 


第 3 种 称 为 狂 确 的 消 筷 投递 。 也 束 是 所 有 的 消息 保证 被 精确 地 投递 
并 成 功 接收 一 次 ， 既 不 会 有 丢失 ， 也 不 会 有 重复 接收 。 


很 明显 ， 第 1 种 策略 是 最 高 性 能 ， 最 低 成 本 的 。 因 为 系统 只 要 负责 
把 消息 送出 去 就 可 以 了 ， 不 需要 关注 是 否 成 功 。 第 2 种 策略 则 需要 保存 
消息 投递 的 状态 并 不 断 充实 。 而 第 3 种 策略 则 是 成 本 最 高 且 最 不 容易 实 
现 的 。 


那 我 们 是 否 真 的 需要 保证 消 妃 投递 的 可 靠 性 呢 ? 


答案 是 否定 的 。 实 际 上 ， 我 们 没有 必要 在 Akka 层 保证 消 妃 的 可 靠 
性 。 这 样 做 ， 成 本 太 高 了 ， 也 十 没有 必要 的 。 消 恩 的 可 靠 性 更 应 该 在 
应 用 的 业务 层 去 维护 ， 因 为 也 许 在 有 些 时 候 ， 丢 失 一 些 消 轧 完 全 十 符 
合 应 用 要 求 的 。 因 此 ， 在 使 用 Akka 时 ， 需 要 在 业务 层 对 此 进行 保证 。 


此 外 ， 对 于 消息 投递 Akka 可 以 在 一 定 程度 上 保证 顺序 性 。 比 如 ， 
Actor A1 向 A2 顺 序 发 送 了 M1、M2 和 M3 三 条 消息 。Actor A3 向 A2 顺 序 
发 送 了 M4、M5 和 M6 三 条 消 恩 。 那 么 系统 可 以 保证 : 


(1) 如 果 M1 没 有 丢失 ， 那 它 一 定 先 于 M2 和 M3 被 A2 收 到 。 
(2) 如 果 M2 没 有 丢失 ， 那 它 一 定 先 于 M3 被 A2 收 到 。 
(3) 如 果 M4 没 有 丢失 ， 那 它 一 定 先 于 M5 和 M6 被 A2 收 到 。 
(4) 如 果 M5 没 有 丢失 ， 那 它 一 定 先 于 M6 被 A2 收 到 。 


(5) 对 A2 来 说 ， 来 自 Al1 和 A3 的 消息 可 能 交织 在 一 起 ， 没 有 顺序 
保证 。 


在 这 里 ， 值 得 注意 的 一 点 是 ， 这 种 消 朋 投 递 规则 不 具备 可 传递 
Es EEN: 


Actor A 向 C 发 送 了 M1， 接 着 ，Actor A 向 B 发 送 了 M2，B 将 M2 转 
发 给 Actor C。 那 么 在 这 种 情况 下 ，C 收 到 M1 和 M2 的 先后 顺序 是 没有 
保证 的 。 


7.4 Actor 的 生命 周期 


Actor 在 系统 中 产生 后 ， 也 存在 着 "生老病死 "的 活动 周期 。Akka 杠 
架 提 供 了 才干 回调 范 数 ， 让 我 们 得 以 在 Actor 的 活动 周期 内 进行 一 些 业 
务 相 关 的 行为 。Actor 的 生命 周期 如 图 7.1 所 示 。 
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图 7.1 Actor 的 生命 周期 


一 个 Actor 在 actorOf() 函 数 被 调用 后 开始 建立 ，Actor 实 例 创建 后 ， 
会 回调 preStart() 方 法 。 在 这 个 方法 里 ， 我 们 可 以 进行 一 些 资源 的 初始 
化 工作 。 在 Actor 的 工作 过 程 中 ， 可 能 会 出 现 一 些 异 常 ， 这 种 情况 下 ， 
Actor 会 需要 重启 。 当 Actor 被 重启 时 ， 会 回调 preRestart(0) 方 法 (在 老 的 
实例 上 ) ， 接 着 系统 会 创建 一 个 新 的 Actor 对 象 实 例 (虽然 是 新 的 实 
例 ， 但 它们 都 表示 同一 个 Actor) 。 当 新 的 Actor 实 例 创建 后 ， 会 回调 
postRestart() 方 法 ， 表 示 局 动 完 成 ， 同 时 新 的 实例 将 会 代 奉 旧 的 实例 。 
停止 一 个 Actor 也 有 很 多 方式 ， 你 可 以 调用 stop0 方 法 或 者 给 Actor 发 送 


一 个 PosionPill 〈 毒 药丸 ) 。Actor 停 止 时 ，postStop(0) 方 法 会 被 调用 ， 
同时 这 个 Actor 的 监视 者 会 收 到 一 个 Terminated 消 筷 。 


下 面 让 我 们 建立 一 个 市 有 生命 周期 回调 函数 的 Actor: 


public class MyWorker extends UntypedActor { 
private final LoggingAdapter log 
Logging.getLogger(getContext().system(), this); 
public static enum Msg { 
WORKING, DONE, CLOSE; 
} 
@Override 
public void preStart(){ 
System.out.println("MyWorker is starting"); 
} 
@Override 
public void postStop(){ 
System.out.println("MyWorker is stopping"); 
} 
@Override 
public void onReceive(Object msg) { 
if (msg == Msg.WORKING) { 
System.out.println("I am working"); 
} 
if (msg == Msg.DONE) { 
System.out.println("Stop working"); 
}if (msg == Msg.CLOSE) { 


System.out.printin("I will shutdown"); 
getSender().tell(Msg.CLOSE, getSelf()); 
getContext().stop(getSelf()); 

} else 


unhandled(msg); 


上 述 代 码 定 义 了 一 个 名 为 MyWorker 的 Actor。 它 重 载 了 preStart0 和 
postStop0 两 个 方法 。 一 般 来 说 ， 我 们 可 DESO RO 
资源 ， 使 用 postStop(0) 来 进行 资源 的 释放 。 这 个 Actor 很 向 单 ， 当 它 收 到 
WORKING 消 息 时 ， 就 打印 “Iam working”， 收 到 DONE 消 息 时 ， 打 
印 “Stop working” ° 


接着 ， 我 们 为 MyWorker 指 定 一 个 监视 者 ， 监 视 者 就 如 同一 个 劳动 
监工 ， 一 旦 MyWorker 因 为 意外 停止 工作 ， 监 视 者 就 会 收 到 一 个 通知 。 


01 public class WatchActor extends UntypedActor { 
02 private final LoggingAdapter log = 
Logging.getLogger(getContext().system(), this); 


03 

04 public WatchActor(ActorRef ref) { 
05 getContext().watch(ref); 

06 } 

07 

08 @Override 

09 public void onReceive(Object msg) { 


10 if (msg instanceof Terminated) { 


11 System.out.printin(String.format("%s has 
terminated, shutting down system", 

12 ((Terminated) msg).getActor().path())); 
AS getContext().system().shutdown(); 

14 } else { 

HERS unhandled(msg); 


上 述 代 码 定 义 了 一 个 监视 者 WatchActor ， 它 本 质 上 也 是 一 个 
Actor， 但 不 同 的 是 ， 它 会 在 它 的 上 下 文中 watch 一 个 Actor (第 5 行 ) ° 
如 果 将 来 这 个 被 监视 的 Actor 的 退出 终止 ，watchActor 吏 能 收 到 一 条 
Terminated 消 息 (代码 第 10 行 )。 在 这 里 ， 我 们 将 简单 地 打印 终止 消 
息 Terminated 中 的 相关 Actor 路 径 ， 并 且 关 闭 整 个 ActorSystem (第 13 


Is 
EKRA F: 
01 public class DeadMain { 
02 public static void main(String[] args) { 
03 ActorSystem system = ActorSystem 
04 .create("deadwatch", 


ConfigFactory.load("samplehello.conf")); 

05 ActorRef worker = 
system.actorOf(Props.create(MyWorker.class), "worker"); 

06 system.actorOf(Props.create(WatchActor.class, 


worker), "watcher"); 


07 worker.tell(MyWorker .Msg.WORKING, 
ActorRef.noSender()); 

08 worker.tell(MyWorker.Msg.DONE, ActorRef.noSender()); 
09 worker.tell(PoisonPill.getInstance(), 
ActorRef.noSender()); 

10 } 

11 } 


上 述 代 码 中 ， 我 们 首先 创建 ActorSystem 全 局 实例 (3417) , 
接着 创建 MyWorker Actor 和 WatchActor 。 注 意 第 6 行 的 Props.create() 方 
法 ， 它 的 第 1 个 参数 为 要 创建 的 Actor 类 型 ， 第 2 个 参数 为 这 个 Actor 的 
Re HABE 〈 在 这 里 ， 就 是 要 调用 WatchActor 的 构造 西数 ) 。 接 
a 向 MyWorker 先 后 发 送 WORKING 和 DONE 两 条 消息 。 最 后 在 第 9 

， 发 送 一 条 特殊 的 消息 PoisonP 刘 。PoisonP 计 就 是 毒药 丸 ， 它 会 直接 
a 让 其 终止 。 


执行 上 述 代 码 ， 系 统 输出 如 下 : 


MyWorker is starting 

I am working 

Stop working 

MyWorker is stopping 

akka://deadwatch/user/worker has terminated, shutting down 


system 


从 这 个 输出 中 可 以 看 到 ，MYyWorker 生 命 周 期 中 的 两 个 回调 函数 以 
及 消息 处 理 函 数 都 被 正 弟 调用 。 最 后 一 行 输出 也 显示 WatchActor 正 常 
监视 到 MyWorker 的 终止 。 


7.5 监督 策略 


如 果 一 个 Actor 在 执行 过 程 中 发 生意 外 ， 比 如 没有 处 理 某 些 异 常 ， 
导 人 致 出 错 ， 那 么 这 个 时 候 应 该 怎么 办 呢 ? 系统 是 应 该 当做 什么 都 没 发 
生 过 ， 继 续 执行 ， 还 是 认为 遇 到 了 一 个 系统 性 的 错误 而 重启 Actor 甚 至 
征 它 所 有 的 兄弟 Actor 呢 ? 


对 于 这 种 情况 ，Akka 框 架 给 予 了 我 们 足够 的 控制 权 。 在 Akka 框 架 
内 ， 父 Actor 可 以 对 子 Actor 进 行 监督 ， 监 控 Actor 的 行为 是 否 有 异常 。 
大 体 上 ， 监 督 抹 略 可 以 分 为 两 种 ， 一 种 是 OneForOneStrategy 的 监督 ， 
男 外 一 种 是 AllForOneStrategy ° 


对 于 OneForOneStrategy 的 案 略 ， 父 Actor 只 会 对 出 问题 的 子 Actor 
进行 处 理 ， 比 如 重启 或 者 停止 ， 而 对 于 AllForOneStrategy， 父 Actor 会 
对 出 问题 的 子 Actor 以 及 它 所 有 的 兄弟 都 进行 处 理 。 很 显然 ， 对 于 
AllForOneStrategy 策 略 ， 它 更 加 适合 于 各 个 Actor 联 系 非常 紧密 的 场 
景 ， 如 果 多 个 Actor 间 只 要 有 一 个 Actor 出 现 故 障 ， 则 宣告 整个 任务 失 
败 ， 就 比较 适合 使 用 AllForOneStrategy， 否 则 ， 在 更 多 的 场景 中 ， 应 
该 使 用 OneForOneStrategy。 当 然 了 ，OneForOneStrategy 也 是 Akka 的 默 
AIR ° 


在 一 个 指定 的 策略 中 ， 我 们 可 以 对 Actor 的 失败 情况 进行 相应 的 处 
理 ， 比 如 : SAY, RIT AACR Marie, ARBEIT Actor, BR 
什么 事 都 没 发 生 过 一 样 。 或 者 可 以 重 局 这 个 Actor， 甚 至 可 以 让 这 个 
Actor 彻 底 俘 止 工作 。 要 指定 这 些 监督 行为 ， 只 要 构造 一 个 目 定 义 的 监 
督 朱 上 略 即 可 。 


下 面 让 我 们 简单 看 一 下 SupervisorStrategy 的 使 用 和 设置 。 首 先 ， 
需要 定 一 个 父 Actor， 它 作为 所 有 子 Actor 的 监督 者 : 


01 public class Supervisor extends UntypedActor { 
02 private static SupervisorStrategy strategy = new 


OneForOneStrategy(3, Duration.create(1, TimeUnit.MINUTES), 


03 new Function<Throwable, Directive>() { 

04 @Override 

05 public Directive apply(Throwable t) { 

06 if (t instanceof ArithmeticException) { 
07 System.out.println("meet 


ArithmeticException, just resume"); 

08 return SupervisorStrategy.resume(); 
09 } else if (t instanceof 
NullPointerException) { 

10 System.out.println("meet 
NullPointerException, restart"); 

La return SupervisorStrategy.restart(); 
12 } else if (t instanceof 


IllegalArgumentException) { 


13 return SupervisorStrategy.stop(); 
14 } else { 
15 return 


SupervisorStrategy.escalate(); 
16 } 
17 } 


18 }); 


20 @Override 

21 public SupervisorStrategy supervisorStrategy() { 
22 return strategy; 

23 } 

24 

25 public void onReceive(Object o) { 

26 if (o instanceof Props) { 

27 getContext().actorOf((Props) o,"restartActor"); 
28 } else { 

29 unhandled(o); 

30 } 

31 } 

32 } 


上 述 代 码 第 2 一 18 行 ， 定 义 了 一 个 OneForOneStrategy 的 监督 合 
略 。 在 这 个 监督 策略 中 ， 运 行 Actor 在 遇 到 错误 后 ， 在 1 分 钟 内 进行 3 次 
重 试 。 如 果 超 过 这 个 频率 ， 那 么 就 会 直接 杀 死 Actor。 具 体 的 策略 由 第 
5~16 行 定义 。 这 里 的 含义 是 ， 当 人 过 到 ArithmeticException 异 常 时 (HE 
如 除 以 0 的 错误 ) ， 继 续 指 定 这 个 Actor， 不 做 任何 处 理 (第 8 行 ) ; 当 
遇 到 空 指 针 时 ， 进 行 Actor 的 重启 (第 11 行 ) 。 如 果 遇 到 
IllegalArgumentException 异 常 ， 则 直接 停止 Actor (第 13 行 ) 。 对 于 在 
这 个 函数 中 没有 涉及 的 异常 ， 则 向 上 抛 出 ， 由 更 顶层 的 Actor 处 理 (第 
本 何人 
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的 监督 策略 。 


第 27 行 用 来 新 建 一 个 名 为 restartActor 的 子 Actor， 这 个 子 Actor 束 由 
当前 的 Supervisor 进 行 监督 了 。 当 Supervisor 接 收 一 个 Props 对 象 时 ， 就 
会 根据 这 个 Props 配 置 生成 一 个 restartActor ° 


RestartActor 的 实现 如 下 : 


01 public class RestartActor extends UntypedActor { 


02 public enum Msg { 

03 DONE, RESTART 

04 } 

05 

06 @Override 

07 public void preStart() { 

08 System.out.println("preStart hashcode:" + 


this.hashCode()); 


09 } 

10 

11 @Override 

12 public void postStop() { 

13 System.out.println("postStop hashcode:" + 


this.hashCode()); 


14 } 

15 

16 @Override 

17 public void postRestart(Throwable reason) throws 


Exception { 


18 super.postRestart(reason); 


19 


System.out.println("postRestart hashcode:" + 


this.hashCode()); 


20 
21 
22 
23 


@Override 


public void preRestart(Throwable reason,Option opt) 


throws Exception { 


24 


System.out.printin("preRestart hashcode:" + 


this.hashCode()); 


25 
26 
27 
28 
29 
30 
31 
32 
33 


@Override 


public void onReceive(Object msg) { 


if (msg == Msg.DONE) { 
getContext().stop(getSelf()); 

} else if (msg == Msg.RESTART) { 
System.out.println(((Object)null).toString()); 
// 抛 出 异常 默认 会 被 restart， 但 这 里 会 resume 
double a = 0 / 0; 


} 
unhandled(msg); 


第 6 一 25 行 ， 定 义 了 一 些 Actor 的 生命 周期 的 回调 接口 。 目 的 是 更 


好 地 观察 Actor 的 活动 情况 。 在 第 32 一 34 行 模拟 了 一 些 异 常情 况 ， 第 32 


行 会 抛 出 NullPointerException， 而 第 34 行 因为 除 以 零 ， 所 以 会 抛 出 


ArithmeticException ° 
主 函 数 如 下 定义 : 


01 public static void customStrategy(ActorSystem system) { 

02 ActorRef a = 
system.actorOf(Props.create(Supervisor.class), "Supervisor"); 
03 a.tell(Props.create(RestartActor.class), 
ActorRef.noSender()); 

04 

05 ActorSelection 
sel=system.actorSelection("akka://lifecycle/user/Supervisor/res 


tartActor"); 


06 
07 for(int i=0;i<100;i++){ 
08 sel.tell(RestartActor .Msg.RESTART, 


ActorRef.noSender()); 

09 } 

10 } 

11 public static void main(String[] args) { 

12 ActorSystem system = ActorSystem.create("lifecycle", 
ConfigFactory.load("lifecycle.conf")); 

13 customStrategy(system); 

14 } 


上 述 代 码 中 ， 第 12 行 代码 创建 了 全 局 ActorSystem ， 接 着 在 
customStrategy() NAM F Bl T Supervisor Actor， 并 且 对 Supervisor 发 送 


一 个 RestartActor 的 Props (第 3 行 ， 这 个 消息 会 使 得 Supervisor 创 建 
RestartActor) 。 


接着 ， 选 中 RestartActor 实 例 (第 5 行 ) 。 第 7 一 9 行 ， 癌 这 个 


RestartActor 发 送 100 条 RESTART 消 息 。 这 会 使 得 RestartActor 抛 出 


NullPointerException ° 


执行 上 述 代码 ， 部 分 输出 如 下 (由 于 输出 太 多 ， 这 里 只 截取 重要 
的 部 分 ) 


01 preStart hashcode:7302437 

02 meet NullPointerException, restart 

03 preRestart hashcode: 7302437 

04 [ ERROR ] [lifecycle-akka.actor.default-dispatcher -3] 
[akka://lifecycle/user/Supervisor/ 

restartActor] null 

05 java.lang.NullPointerException 

06 at 
geym.akka.demo.lifecycle.RestartActor.onReceive(RestartActor.ja 
va: 46) 

07 at 
akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedA 
ctor.scala:167) 

08 at akka.actor.Actor$class.aroundReceive(Actor.scala: 465) 
09 at 
akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97) 

10 at 


akka.actor.ActorCell.receiveMessage(ActorCell.scala:516) 


11 at akka.actor.ActorCell.invoke(ActorCell.scala: 487) 

12 at 
akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254) 

Ls at akka.dispatch.Mailbox.run(Mailbox.scala:221) 

14 at akka.dispatch.Mailbox.exec(Mailbox.scala: 231) 

15 at 


scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask. java 


:260) 


16 


at 


scala.concurrent.forkjoin.ForkJoinPool$workQueue.runTask(ForkJo 


inPool. java:1339) 


17 


at 


scala.concurrent.forkjoin.ForkJoinPool.runworker(ForkJoinPool. j 


ava:1979) 


18 


at 


scala.concurrent.forkjoin.ForkJoinWworkerThread.run(ForkJoinWork 


erThread. java:107 ) 


19 
20 
21 
22 
23 
24 
25 
26 
27 
28 


preStart hashcode:23269863 
postRestart hashcode: 23269863 
meet NullPointerException, restart 
preRestart hashcode: 23269863 
preStart hashcode: 24918371 
postRestart hashcode: 24918371 
meet NullPointerException, restart 
preRestart hashcode: 24918371 


preStart hashcode:12844205 


29 postRestart hashcode:12844205 
30 [ERROR] [lifecycle-akka.actor.default-dispatcher -2] 
[akka://lifecycle/user/Supervisor/restartActor] n ull 


31 meet NullPointerException, restart 


33 postStop hashcode:12844205 


第 1 行 的 preStart 表 示 RestartActor 正 在 初始 化 ， 注 意 它 的 HashCode 
为 7302437。 接 着 ， 这 个 Actor 遇 到 了 NullPointerException。 根 据 目 定义 
的 策略 ， 这 将 导致 它 重启 ， 因 此 ， 这 就 有 了 第 3 行 的 preRestart， 因 为 
preRestart 在 正式 重启 之 前 调用 ， 因 此 HashCode 还 是 7302437， 表 示 当 
前 Actor 和 上 一 个 Actor 还 是 同一 个 实例 。 接 着 ， 第 4 一 19 行 打印 了 异常 


ays 
信息 。 


第 20 行 进入 了 preStart0 方 法 ， 它 的 HashCode 为 23269863。 这 说 明 
系统 已 经 为 这 个 RestartActor 生 成 了 一 个 新 的 实例 ， 原 有 的 实例 因为 重 
启 而 被 回收 。 新 的 实例 将 代替 原 有 实例 继续 工作 。 这 说 明 同 一 个 
RestartActor 在 系统 的 工作 始终 ， 未 必 能 你 持 同一 个 实例 。 重 启 完成 
后 ， 调 用 postRestart() 方 法 (第 21 行 ) 。 实 际 上 ，Actor 重 启 后 的 
preStart() 方 法 ， 束 是 在 postRestart() 中 调用 的 (Actor 父 类 的 postRestart() 
会 调用 preStart0 方 法 ) ° 


在 经 过 3 次 重启 后 ， 超 过 了 监督 策略 中 的 单位 时 间 内 的 重 试 上 限 。 
因此 ， 系 统 不 会 再 进行 和 尝试 ， 而 是 直接 关闭 RestartActor。 上 壕 输 出 中 
第 33 行 就 显示 了 这 个 过 程 ， 在 最 后 一 个 RestartActor 实 例 上 ， 执 行 了 集 
止 方法 。 


7.0 选择 Actor 


在 一 个 ActorSystem 中 ， 可 能 存在 大 量 的 Actor。 如 何 才 能 有 效 地 对 
大 量 Actor 进 行 批量 的 管理 和 通信 了 昵 ? Akka 为 我 们 提供 了 一 个 
ActorSelection 类 ， 用 来 批量 进行 消息 发 送 。 限 于 篇 幅 有 限 ， 这 里 不 再 
给 出 完整 的 代码 ， 示 意 代 码 如 下 : 


1 for(int i=0;i<WORDER COUNT;i++){ 

2 

workers.add(system.actorOf(Props.create(MyWorker.class,i), 
"worker_"+1)); 

3 } 

4 

5 ActorSelection selection = 
getContext().actorSelection("/user/worker_*"); 


6 selection.tell(5, getSelf()); 


上 述 代 码 第 1~3 行 ， 批 量 生成 了 大 量 Actor。 接 着 ， 我 们 要 给 这 些 
worker 发 送 消 息 ， 通 过 actorSelection0) 方 法 提供 的 选择 通配符 (第 5 
fT) ， 可 以 得 到 代表 所 有 满足 条 件 的 ActorSelection。 第 6 行 ， 通 过 这 个 
ActorSelection 实 例 ， 便 可 以 向 所 有 woker Actor 发 送 消 息 。 


7.7 ”消息 收 件 箱 (Inbox) 


我 们 已 经 知道 ， 所 有 Actor 之 间 的 通信 都 是 通过 消 恩 来 进行 的 。 这 
是 否 意 味 着 我 们 必须 构建 一 个 Actor 来 控制 整个 系统 呢 ? 答案 是 否定 
的 ， 我 们 并 不 一 定 要 这 么 做 ，Akka 框 架 已 经 为 我 们 准备 了 一 个 叫 
做 <“ 收 件 箱 ” 的 组 件 ， 使 用 收 件 箱 ， 可 以 很 方便 地 对 Actor 进 行 消息 发 送 
和 接收 ， 大 大 方便 了 应 用 程序 与 Actor 之 间 的 交互 。 


下 面 定 义 了 当前 示例 中 唯一 一 个 Actor: 


01 public class MyWorker extends UntypedActor { 
02 private final LoggingAdapter log = 
Logging.getLogger(getContext().system(), this); 


03 public static enum Msg { 

04 WORKING, DONE, CLOSE; 

05 } 

06 

07 @Override 

08 public void onReceive(Object msg) { 
09 if (msg == Msg.WORKING) { 

10 log.info("I am working"); 
11 } 

由 用 if (msg == Msg.DONE) { 

13 log.info("Stop working"); 
14 }if (msg == Msg.CLOSE) { 


LS log.info("I will shutdown"); 


16 getSender().tell(Msg.CLOSE, getSelf()); 


17 getContext().stop(getSelf()); 
18 } else 

19 unhandled(msg); 

20 } 

21 } 


上 述 代 码 中 ，MyWorker 会 根据 收 到 的 消息 打印 目 己 的 工作 状态 。 
当 接 收 到 CLOSE 消息 时 〈 第 14 行 ) ， 会 关闭 自己 ， 结 束 运 行 。 


而 在 本 例 中 ， 与 这 个 MyWorker Actor 交 互 的 ， 并 不 是 一 个 Actor， 
而 是 一 个 邮箱 ， 邮 箱 的 使 用 很 简单 : 


01 public static void main(String[] args) { 

02 ActorSystem system = ActorSystem.create("inboxdemo", 
ConfigFactory.load("samplehello.conf")); 

03 ActorRef worker = 
system.actorOf(Props.create(MyWorker.class), "worker"); 

04 

05 final Inbox inbox = Inbox.create(system); 

06 inbox.watch(worker); 

07 inbox.send(worker, MyWorker .Msg.WORKING); 

08 inbox.send(worker, MyWorker.Msg.DONE); 

09 inbox.send(worker, MyWorker.Msg.CLOSE) ; 

10 

11 while(true){ 

12 Object msg = inbox.receive(Duration.create(1, 


TimeUnit.SECONDS) ); 


13 if (msg==MyWorker .Msg.CLOSE) { 


14 System.out.printin("My worker is Closing"); 
15 selse if(msg instanceof Terminated) { 

16 System.out.printin("My worker is dead"); 

17 System,Shutdown() ， 

18 break; 

19 selse{ 

20 System.out.printlin(msg); 

21 } 

22 3} 

234} 


上 述 代 码 中 ， 第 5 行 ， 根 据 ActorSystem 构 造 了 一 个 与 之 绑 定 的 邮 
箱 Inbox。 接 着 使 用 邮箱 监视 MyWorker (第 6 行 ) ， 这 样 就 能 在 
MyWorker 停 止 后 得 到 一 个 消息 通知 。 第 7 一 9 行 ， 通 过 邮箱 辣 
MyWorker 发 送 消 息 。 


在 第 11~21 行 ， 进 行 消 上 息 接 收 ， 如 果 发 现 MyWorker 已 经 停止 工 
作 ， 则 关闭 整个 ActorSystem (第 17 行 ) ° 


执行 上 述 代 码 ， 输 出 如 下 (为 节省 版 面 ， 我 对 输出 进行 了 一 些 简 
单 的 删 减 ) : 


[INFO] [inboxdemo-akka.actor.default-dispatcher-3] 
[akka://inboxdemo/user/worker] I am 

working 

[INFO] [inboxdemo-akka.actor.default-dispatcher-3] 


[akka://inboxdemo/user/worker] Stop 


working 

[INFO] [inboxdemo-akka.actor.default-dispatcher-3] 
[akka://inboxdemo/user/worker] I will 

shutdown 

My worker is Closing 


My worker is dead 


上 述 输 出 的 前 3 行为 MyWorker 的 输出 日 志 ， 表 示 MyWorker Actor 
的 工作 状态 。 后 两 行为 主 男 数 main0 中 对 MyWorker 消 息 的 处 理 。 
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Akka 提 供 了 非常 灵活 的 消息 发 送 机 制 。 有 时 候 ， 我 们 也 许 会 使 用 
一 组 Actor 而 不 是 一 个 Actor 来 提供 一 项 服务 。 这 一 组 Actor 中 所 有 的 
Actor 都 是 对 等 的 ， 也 就 是 说 你 可 以 找 任何 一 个 Actor 来 为 你 服务 。 这 
种 情况 下 ， 如 何 才 能 快速 有 效 地 找到 合适 的 Actor 呢 ? 或 者 说 如 何 调度 
这 些 消息 ， 才 可 以 使 负载 更 为 均衡 地 分 配 在 这 一 组 Actor 中 。 


为 了 解决 这 个 问题 ，Akka 使 用 一 个 路 由 器 组 件 (Router) 来 封装 
消 妃 的 调度 。 系 统 提 供 了 几 种 实用 的 消息 路 由 党 略 ， 比 如 ， 轮 询 选 择 
Actor 进 行 消 恩 发 送 ， 随 机 消 恩 发 送 ， 将 消 居 发 送 给 最 为 空 内 的 
Actor， 甚 至 是 在 组 内 广播 消息 。 


下 面 束 来 演示 一 下 消 奶 路 由 的 使 用 方式 : 


01 public class WatchActor extends UntypedActor { 
02 private final LoggingAdapter log = 
Logging.getLogger(getContext().system(), this); 


03 public Router router; 

04 { 

05 List<Routee> routees=new ArrayList<Routee>(); 

06 for(int 1=0;1<5;it++){ 

07 ActorRef worker = 


getContext().actorOf(Props.create(MyWorker.class), "worker_"+1); 
08 getContext().watch(worker ); 


09 routees.add(new ActorRefRoutee(worker ) ); 


10 } 
11 router=new 


RoundRobinRoutingLogic(),routees); 


12 } 

13 

14 @Override 

15 public void onReceive(Object msg) { 

16 if(msg instanceof MyWorker.Msg) { 

17 router.route(msg, getSender()); 

18 yelse if (msg instanceof Terminated) { 
19 


router=router.removeRoutee(((Terminated)msg).actor()); 
20 
System.out.printin(((Terminated)msg).actor().path()+" 
closed, routees="+router. 


routees().size()); 


21 if(router.routees().size()==0) { 

22 System.out.println("Close system"); 
23 RouteMain.flag.send(false); 

24 getContext().system().shutdown(); 
25 } 

26 } else { 

27 unhandled(msg); 

28 } 

29 } 


Router (new 


is 


上 述 代 人 码 中 定义 了 WatchActor ° 83747, Wi Bs H rrF Router, 
在 构造 Router 时 ， 需 要 指定 路 由 策略 和 一 组 被 路 由 的 Actor 
(Routee) ， 如 第 11 行 所 示 。 这 里 使 用 了 RoundRobinRoutingLogic 路 由 
RIE, thie XT ATA AY Routeewt (TFA A AIK ° EAF, Routee 
由 5 个 MyWorker Actor 构 成 〈 第 6 一 10 行 ，MyWorker 与 上 一 节 中 的 相 
同 ， 故 不 再 给 出 代码 ) o 


当 有 消息 需要 传递 给 这 5 个 MyWorker 时 ， 只 需要 将 消息 投递 给 这 
个 Router 即 可 (上述 代码 第 17 行 )。Router 就 会 根据 给 定 的 消息 路 由 策 
略 进行 消息 投递 。 当 一 个 MyWorker 停 止 工作 时 ， 还 可 以 简单 地 将 其 从 
工作 组 中 移 除 (第 19 行 ) 。 在 这 里 ， 如 果 发 现 系 统 中 没有 可 用 的 
Actor， 吏 会 直接 关闭 系统 。 


主 函 数 比 较 简单 ， 如 下 : 


01 public class RouteMain { 

02 public static Agent<Boolean> flag=Agent.create(true, 
ExecutionContexts.global()); 

03 public static void main(String[ ] args) throws 
InterruptedException { 

04 ActorSystem system = ActorSystem.create("route", 
ConfigFactory.load("samplehello.conf")); 

05 ActorRef 


w=system.actorOf(Props.create(WatchActor.class), "watcher"); 


06 int i=1; 
07 while(flag.get()){ 
08 w.tell(Myworker.Msg.WORKING, ActorRef.noSender()); 


09 if (i%10==0)w.tell(MyWworker .Msg.CLOSE, 


ActorRef.noSender()); 


10 itt; 

11 Thread.sleep(100) ; 
12 } 

13° 4 

14 } 


oe 回 WatchActor 发 送 大 量 消息 ， 其 中 Tan 关闭 Actor 
的 消息 。 这 会 使 得 MyWorker Actor 逐 一 被 关闭， 最 终 程序 将 退出 。 


这 段 程序 的 部 分 输出 如 下 《做 过 适量 裁 蔓 ) 


[INFO][route-akka.actor.default-dispatcher -3] 
[akka://route/user/watcher/worker_O] I am 
working 

[INFO] [route-akka.actor.default-dispatcher -3] 
[akka://route/user/watcher/worker_1] I am 
working 

[ INFO][route-akka.actor.default-dispatcher -3] 
[akka://route/user/watcher/worker_2] I am 
working 

[INFO] [route-akka.actor.default-dispatcher -4] 
[akka://route/user/watcher/worker_3] I am 
working 
[INFO][route-akka.actor.default-dispatcher -3] 
[akka://route/user/watcher/worker_4] I am 
working 


[INFO][route-akka.actor.default-dispatcher -3] 


[akka://route/user/watcher/worker_0O] I am 


working 


[ INFO][route-akka.actor.default-dispatcher -2] 
[akka://route/user/watcher/worker_0] I will 

shutdown 

akka://route/user/watcher/worker_1 is closed, routees=0 


Close system 


可 以 看 到 ，WORKING 消 息 被 轮流 发 送 给 这 5 个 worker。 大 家 可 以 
修改 路 由 策略 ， 观 察 不 同 路 由 策略 下 的 消息 投递 方式 〈 除 了 
RoundRobinRoutingLogic 外 ， 还 可 以 尝试 BroadcastRoutingLogic 广 播 策 
略 、RandomRoutingLogic 随 机 投递 策略 、SmallestMailboxRoutingLogic 
空 内 Actor 优 先 投递 策略 ) 。 


7.9 Actor 的 内 置 状态 转换 


在 很 多 场景 下 ，Actor 的 业务 逻辑 可 能 比较 复杂 ，Actor 可 能 需要 
根据 不 同 的 状态 对 同一 条 消息 作出 不 同 的 处 理 。Akka 已 经 为 我 们 考虑 
到 了 这 一 点 ， 一 个 Actor 内 部 消息 处 理 函 数 可 以 拥有 多 个 不 同 的 状态 ， 
在 特定 的 状态 下 ， 可 以 对 同一 消息 进行 不 同 的 处 理 ， 状 态 之 间 也 可 以 
任意 切换 。 


现在 让 我 们 模拟 一 个 婴儿 Actor， 假 设 婴 儿 会 拥有 两 种 不 同 的 状 
态 ， 开 心 或 者 生气 。 当 你 带 他 玩 的 时 候 ， 他 总 是 会 表现 出 开心 状态 ， 
当 你 让 他 睡觉 时 ， 他 束 会 非常 生气 ， 小 孩子 总 是 拥有 用 不 完 的 精力 ， 
入 睡 困难 可 能 是 一 种 通病 吧 ! 


在 我 们 这 个 简单 的 场景 模拟 中 ， 我 们 会 给 这 个 婴儿 Actor 发 送 睡觉 
和 玩 两 种 指令 。 如 果 婴 儿 正在 生气 ， 你 还 让 他 睡觉 ， 他 就 会 说 "我 已 经 
生气 了 ”， 如 果 你 让 他 去 玩 ， 他 就 会 变 得 开心 起 来 。 同 样 ， 如 果 他 正 玩 
得 高 兴 ， 你 让 他 继续 玩 ， 他 就 会 说 < 我 已 经 很 愉快 了 *， 如 果 让 他 睡 
觉 ， 他 就 马上 变 得 很 生气 。 


下 面 的 这 个 BabyActor 束 模拟 了 上 壕 场景 : 


01 public class BabyActor extends UntypedActor { 

02 private final LoggingAdapter log = 
Logging.getLogger(getContext().system(), this); 

03 public static enum Msg { 

04 SLEEP, PLAY, CLOSE; 


05 } 


06 

07 Procedure<Object> angry = new Procedure<Object>() { 
08 @Override 

09 public void apply(Object message) { 

10 System.out.printin("angryApply:"+message) ; 

11 if (message == Msg.SLEEP) { 

12 getSender().tell("I am already angry", 


getSelf()); 


LE System.out.println("I am already angry"); 
14 } else if (message == Msg.PLAY) { 

15 System.out.println("I like playing"); 

16 getContext().become(happy) ; 

17 } 

18 

19 ti 

20 

21 Procedure<Object> happy = new Procedure<Object>() { 
22 @Override 

23 public void apply(Object message) { 

24 System.out.printlin("happyApply:"+message) ; 

25 if (message == Msg.PLAY) { 

26 getSender().tell("I am already happy :-)", 


getSelf()); 
27 

Sy a 
28 


System.out.println("I am already happy 


} else if (message == Msg.SLEEP) { 


29 System.out.printin("I don't want to sleep"); 


30 getContext().become(angry); 
31 } 

32 } 

33 7 

34 

35 @Override 

36 public void onReceive(Object msg) { 

37 System.out.printin("onReceive:"+msg); 
38 if (msg == Msg.SLEEP) { 

39 getContext().become(angry); 

40 } else if (msg == Msg.PLAY) { 

41 getContext().become(happy); 

42 } else { 

43 unhandled(msg); 

44 } 

45 } 

46 } 


上 述 代 码 中 ， 使 用 了 become() 方 法 用 于 切换 Actor 的 状态 (第 39、 
41 行 ) 。 方 法 become() 接 收 一 个 Procedure 参 数 。Procedure 在 这 里 可 以 
表示 一 种 Actor 的 状态 ， 同 时 ， 更 重要 的 是 它 封闭 了 在 这 种 状态 下 的 消 
FA SDH So 


在 这 个 BabyActor 中 ， 定 义 了 两 种 Procedure， 一 是 angry 生 气 (第 7 
行 ) ， 另 一 个 是 happy 开 心 (82147) ° 


在 初始 状态 下 ，BabyActor 既 没有 生气 也 不 开心 。 因 此 angry 处 理 
函数 和 happy 处 理 函 数 都 不 会 工作 。 当 BabyActor 接 收 到 消息 时 ， 系 统 
会 调用 onReceive() 方 法 来 处 理 这 个 消 忌 。 


令 人 吃惊 的 魔法 就 在 这 个 onReceive() 范 数 中 。 当 onReceive() 处 理 
SLEEP 消息 时 ， 它 会 切换 当前 Actor 的 状态 为 angry (第 39 行 ) 。 如 果 是 
PLAY 消息 ， 则 切换 状态 为 happy 。 


一 旦 完成 状态 切换 ， 当 后 续 有 新 的 消息 送 达 时 ， 残 不 会 再 由 
onReceive(O) 函 数 处 理 了 。 由 于 angry 和 happy 本 号 就 是 消息 处 理 函 数 。 
因此 ， 后 续 的 消息 就 直接 交 由 当前 状态 处 理 (angry 或 者 happy) ， 从 
而 很 好 地 封装 了 Actor 的 多 个 不 同 处 理 逻 辑 。 


下 面 的 代码 向 我 们 的 婴儿 Actor 发 送 了 几 条 PLAY 和 SLEEP 的 消 


1 ActorSystem system = ActorSystem.create("become", 
ConfigFactory.load("samplehello.conf")); 

2 ActorRef child = 
system.actorOf(Props.create(BabyActor.class), "baby"); 

3 system.actorOf(Props.create(WatchActor.class, child), 
"watcher"); 

4 child.tell(BabyActor.Msg.PLAY, ActorRef.noSender()); 
child.tell(BabyActor.Msg.SLEEP, ActorRef.noSender()); 
child.tell(BabyActor.Msg.PLAY, ActorRef.noSender()); 
child.tell(BabyActor.Msg.PLAY, ActorRef.noSender()); 


oO Oo ~ DO UW 


child.tell(PoisonPill.getInstance(), ActorRef.noSender()); 


其 输出 如 下 《进行 过 适量 裁剪 ) : 


onReceive: PLAY 

happyApply : SLEEP 

I don't want to sleep 

angryApply : PLAY 

I like playing 

happyApply : PLAY 

I am already happy :-) 

[INFO] [akka://become/user/watcher] akka://become/user/baby has 
terminated, shutting down 


system 


Lee], 4 F—PSPLAYIE RART, ce HonReceive() KUT 
Ah HEA, Œ onReceive0 F, Actor WJ $k X happy KA ° Ak, 4 
SLEEP} WASIT, Fahappy.apply) KANE, #4 Actor] Hangry 
状态 。 当 PLAY 消息 再 次 到 达 时 ， 由 angry.apply0O 函 数 处 理 。 由 此 可 
见 ，Akka 为 Actor 提 供 了 有 灵活 的 状态 切换 机 制 ， 处 于 不 同 状态 的 Actor 
可 以 绑 定 不 同 的 消息 处 理 函 数 进行 消息 处 理 ， 这 对 构造 结构 化 应 用 有 
着 重要 的 帮助 。 


7.10 询问 模式 : Actor 中 的 Future 


由 于 Actor 之 间 都 是 通过 异步 消息 通信 的 。 当 你 发 送 一 条 消息 给 一 
个 Actor 后 ， 你 通常 只 能 等 eine 返回 。 与 同步 方法 不 同 ， 在 你 发 
送 异 步 消 息 后 ， 接 受 消 恩 的 Actor 可 能 还 根本 来 不 及 处 理 你 的 消 恩 ， 而 
调用 方 束 已 经 返回 了 。 


这 种 模式 与 我 们 之 前 提 到 的 Future 模 式 非常 相像 。 不 同 之 处 只 是 
在 传统 的 异步 调用 中 ， 我 们 进行 的 是 函数 调用 ， 但 在 这 里 ， 我 们 发 送 
了 一 条 消息 。 


因为 两 者 的 行为 方式 是 如 此 相像 ， 因 此 我 们 残 会 很 目 然 地 想到 
当 我 们 需要 一 个 有 返回 值 的 调用 时 ，Actor 是 不 是 也 应 该 给 我 们 一 个 丰 
2) (Future) “a ci MARIA PIB IIE A ANAK Actor Ay) Ah E 
结果 ， 在 将 来 ， 这 个 契约 还 是 可 以 追踪 到 我 们 的 请 求 的 。 


01 import static akka.pattern.Patterns.ask; 
02 import static akka.pattern.Patterns.pipe; 
03 


04 public class AskMain { 


05 

06 public static void main(String[] args) throws Exception 
{ 

07 ActorSystem system = ActorSystem.create("askdemo", 


ConfigFactory.load("samplehello.conf")); 


08 ActorRef worker = 


system.actorOf(Props.create(MyWorker.class), "worker"); 
09 ActorRef printer = 
system.actorOf(Props.create(Printer.class), "printer"); 
10 system.actorOf(Props.create(WatchActor.class, 


worker), "watcher"); 


11 

12 // 等 待 future 返 回 

13 Future<Object> f = ask(worker, 5, 1500); 

14 int re = (int) Await.result(f, Duration.create(6, 


TimeUnit.SECONDS) ); 


15 System.out.println("return:" + re); 

16 

17 // 直 接 导 向 其 他 Actor，pipe 不 会 等 待 

18 f = ask(worker, 6, 1500); 

19 pipe(f, system.dispatcher()).to(printer); 

20 

21 worker.tell(PoisonPill.getInstance(), 


ActorRef.noSender()); 
22 } 
23 } 


上 述 代 码 给 出 了 两 处 在 Actor 交 互 中 使 用 Future 的 例子 。 


在 第 13 行 ， 使 用 ask0 方 法 给 worker 发 送 消 息 ， 消 息 内 容 是 5， 也 就 
说 worker 会 接收 到 一 个 Integer 消 息 ， 值 为 5。 当 workder 接 收 到 消息 后 ， 
束 可 以 进行 计算 处 理 ， 并 且 将 结果 返回 给 发 送 者 。 当 然 ， 这 个 处 理 过 
程 可 能 需要 花费 一 点 时 间 。 


方法 ask0) 不 会 等 待 worker 处 理 ， 会 立即 返回 一 个 Future 对 象 (第 13 
行 ) 。 在 第 14 行 ， 我 们 使 用 Await 方 法 等 待 worker 的 返回 ， 接 着 在 第 15 
行 打印 返回 结果 。 


在 这 种 方法 中 ， 我 们 间接 地 将 一 个 异步 调用 转 为 同步 阻塞 调用 。 
虽然 比较 容易 理解 ， 但 是 在 有 些 场合 可 能 会 出 现 性 能 问题 。 另 外 一 种 
更 为 有 效 的 方法 是 使 用 pipe() 落 数 。 


代码 第 18 行 使 用 askO 再 次 询问 worker， 并 传递 数值 6 给 worker。 接 
着 并 不 进行 等 待 ， 而 是 使 用 pipe0 将 这 个 Future 重 定 癌 到 另外 一 个 称 为 
printer 的 Actor。pipe() 芳 数 不 会 阻塞 程序 ， 会 立即 返回 。 


这 个 printer 的 实现 很 消 单 的 ， 只 走 简 单 地 输出 得 到 的 数据 ; 


01 @Override 


02 public void onReceive(Object msg) { 


03 if (msg instanceof Integer) { 

04 System.out.printin("Printer:"+msg); 
05 } 

06 if (msg == Msg.DONE) { 

07 log.info("Stop working"); 

08 }if (msg == Msg.CLOSE) { 

09 log.info("I will shutdown"); 

10 getSender().tell(Msg.CLOSE, getSelf()); 
11 getContext().stop(getSelf()); 

12 } else 

13 unhandled(msg); 


14 } 


上 述 代 码 就 是 Printer Actor 的 实现 ， 它 会 通过 pipe() 方 法 得 到 worker 
的 输出 结果 ， 并 打印 在 控制 台 上 (第 4 行 ) 。 


在 本 例 中 ，worker Actor 接 受 一 个 整数 ， 并 计算 它 的 平方 ， 并 给 予 
[5] ° 如 下 : 


01 @Override 


02 public void onReceive(Object msg) { 


03 if (msg instanceof Integer) { 

04 int i=(Integer)msg; 

95 Cry at 

06 Thread.sleep(1000); 

07 } catch (InterruptedException e) {} 
08 getSender().tell(i*i, getSelf()); 
09 } 

10 if (msg == Msg.DONE) { 

11 log.info("Stop working"); 

12 }if (msg == Msg.CLOSE) { 

13 log.info("I will shutdown"); 

14 getSender().tell(Msg.CLOSE, getSelf()); 
aS: getContext().stop(getSelf()); 

16 } else 

17 unhandled(msg); 

18 } 


上 述 代 码 第 5 全 7 行 ， 模 拟 了 一 个 耗 时 的 调用 ， 为 了 更 明显 地 说 明 
ask0 和 pipe0) 方 法 的 用 途 。 第 8 行 ，worker 计 算 了 给 定数 值 的 平方 ， 并 
把 它 “ 告 诉 ” 请 求 者 。 


711 多 个 Actor 同 时 修改 数据 : 
Agent 


在 Actor 的 编程 模型 中 ，Actor 之 间 主 要 通过 消息 进行 信息 传递 。 
因此 ， 很 少 发 生 多 个 Actor 需 要 访问 同一 个 共享 变量 的 情况 。 但 在 实际 
开发 中 ， 这 种 情况 很 难 完全 避免 。 那 如 果 多 个 Agent 需 要 对 同一 个 共 吝 
变量 进行 读 写 时 ， 如 何 保证 线程 安全 呢 ? 


在 Akka 中 ， 使 用 一 种 叫做 Agent 的 组 件 来 实现 这 个 功能 。 一 个 
Agent 提 供 了 对 一 个 变量 的 异步 更 新 。 当 一 个 Actor 和 希望 改变 Agent 的 值 
时 ， 它 会 癌 这 个 Agent 下 发 一 个 动作 (action) 。 当 多 个 Actor 同 时 改变 
Agent 时 ， 这 些 action 将 会 在 ExecutionContext 中 被 并 发 调度 执行 。 在 任 
意 时 刻 ， 一 个 Agent 最 多 只 能 执行 一 个 action， 对 于 某 一 个 线程 来 说 ， 
它 执 行 action 的 顺序 与 它 的 发 生 顺 序 一 致 ， 但 对 于 不 同 线程 来 说 ， 这 些 


action 可 能 会 交织 在 一 起 。 


Agent 的 修改 可 以 使 用 两 个 方法 send0 或 者 alter0。 它 们 都 可 以 回 
Agent 发 送 一 个 修改 动作 。 但 是 send() 方 法 没有 返回 值 ， 而 alter0) 方 法 会 
返回 一 个 Future 对 象 便于 跟踪 Agent 的 执行 。 


下 面 让 我 们 模拟 这 么 一 个 场景 : 有 10 个 Actor， 它 们 一 起 对 一 个 
Agent 执 行 累加 操作 ， 每 个 agent 累 加 10000 次 ， 如 果 没 有 意外 ， 那 么 
agent 最 终 的 值 将 是 100000， 如 果 Actor 间 的 调度 出 现 问题 ， 那 么 这 个 值 
可 能 小 于 100000。 


01 public class CounterActor extends UntypedActor { 


02 Mapper addMapper = new Mapper<Integer, Integer>() { 
03 @Override 

04 public Integer apply(Integer i) { 

05 return i+1; 

06 } 

07 7 

08 

09 @Override 

10 public void onReceive(Object msg) { 

11 if (msg instanceof Integer) { 

12 for (int i = 0; 1 < 10000; i++) { 

13 // 我 希望 能 够 知道 future 何 时 结束 

14 Future<Integer> f = 


AgentDemo.counterAgent.alter(addMapper ) ; 


15 AgentDemo. futures.add(f); 
16 } 

17 getContext().stop(getSelf()); 
18 } else 

19 unhandled(msg); 

20 } 

21 } 


上 述 代 码 定 义 了 一 个 累加 的 Actor: CounterActor ° #2~747, Æ 
义 了 款 计 动作 action addMapper。 它 的 作用 是 对 Agent 的 值 进行 修改 ， 
这 里 简单 地 加 1 。 


CounterActor A) 7A J‘ “hb FH EW BY onReceive(.) 中 ， 对 全 局 的 
counterAgent 进 行 累加 操作 ，alter0 指 定 了 累加 动作 addMapper (第 14 
行 ) 。 由 于 我 们 希望 在 将 来 知道 标 加 行为 是 否 完成 ， 因 此 在 这 里 将 返 
回 的 Future 对 象 进行 收集 〈 第 15 行 ) 。 完 成 任务 后 ，Actor 上 自行 退出 

(第 17 行 ) 。 


程序 的 主 函 数 如 下 : 


01 public class AgentDemo { 

02 public static Agent<Integer> counterAgent = 
Agent.create(0, ExecutionContexts.global()); 

03 static ConcurrentLinkedQueue<Future<Integer>> futures 
= new ConcurrentLinkedQueue< Future 

<Integer>>(); 

04 

05 public static void main(String[] args) throws 
InterruptedException { 

06 final ActorSystem system = 


ActorSystem.create("agentdemo", 


07 ConfigFactory.load("samplehello.conf")); 

08 ActorRef[] counter = new ActorRef [10]; 

09 for (int i = 0; i < counter.length; i++) { 

10 counter[i] = 
system.actorOf(Props.create(CounterActor.class), "counter_" + 
1); 

aa } 


12 final Inbox inbox = Inbox.create(system); 


13 for (int i = 0; i < counter.length; i++) { 


14 inbox.send(counter[i], 1); 

15 inbox.watch(counter[i]); 

16 } 

17 

18 int closeCount = 0; 

19 // 等 待 所 有 Actor 全 部 结束 

20 while (true) { 

21 Object msg = inbox.receive(Duration.create(1, 


TimeUnit.SECONDS) ); 


22 if (msg instanceof Terminated) { 

23 closeCount++; 

24 if (closeCount == counter.length) { 
25 break; 

26 } 

27 } else { 

28 System.out.println(msg); 

29 } 

30 } 

31 // 等 每 所 有 的 累加 线程 完成 , 因为 他 们 都 是 异步 的 

32 Futures.sequence(futures, 


system.dispatcher()).onComplete( 


33 new OnComplete<Iterable<Integer>>() { 
34 @Override 
35 public void onComplete(Throwable arg0， 


Iterable<Integer> argi) throws Throwable { 


36 System.out.println("counterAgent=" + 


counterAgent.get()); 


37 system. shutdown(); 
38 J 

39 }, system.dispatcher()); 
40 } 

41 } 


ERREF, 8~11í7, fl] T 10^CounterActor R ° B12~ 
16í7, 1E AA Inbox 5 CounterActor wt 47 iÑ (F ° 5814747 AYIA E A A 
CounterActor 进行 累加 操作 。 第 20 一 30 行 系统 将 等 待 所 有 10 个 
CounterActor 运 行 结束 。 执 行 完成 后 ， 我 们 便 已 经 收集 了 所 有 的 
Future。 在 第 32 行 ， 将 所 有 的 Future 进 行 串 行 组 合 (使 用 sequence0 方 
法 ) ,构造 了 一 个 整体 的 Future， 并 为 它 创建 onComplete0 回 调 函 数 。 
在 所 有 的 Agent 操 作 执 行 完 成 后 ，onComplete0) 方 法 就 会 被 调用 (第 35 
行 ) 。 在 这 个 例子 中 ， 我 们 简单 地 输出 最 终 的 counterAgent 值 (第 36 
行 ) ， 并 关闭 系统 (第 37 行 ) © 


执行 上 述 程 序 ， 我 们 将 看 到 ; 


counterAgent=100000 


7.12 ” 像 数 据 库 一 样 操作 内 存 数 
fa: 软件 事务 内 存 


在 一 些 函 数 式 编程 语言 中 ， 文 持 一 种 叫做 软件 事务 内 存 (STM) 
的 技术 。 什 么 是 软件 事务 内 存 呢 ? 这 里 的 事务 和 数据 库 中 所 说 的 事务 
非常 类 似 ， 具 有 隔离 性 、 原 子 性 和 一 致 性 。 与 数据 库 事 务 不 同 的 是 ， 
内 存 事务 不 具备 持久 性 〈 很 显然 内 存 数 据 不 会 保存 下 来 ) 。 


在 很 多 场合 ， 某 一 项 工作 可 能 要 由 多 个 Actor 协 作 完 成 。 在 这 种 协 
作 事 务 中 ， 如 果 一 个 Actor 处 理 失 败 ， 那 么 根据 事务 的 原子 性 ， 其 他 
Actor 所 进行 的 操作 必须 要 回 深 。 下 面 ， 束 让 我 们 来 看 一 个 简单 的 案 
Bill ° 


假设 有 一 个 公司 要 给 他 的 员工 发 放 福 利 ， 公 司 账户 里 有 100 元 。 每 
次 ， 公 司 账户 会 给 员工 账户 转 一 笔 钱 ， 假 设 转 账 10 元 ， 那 么 公司 账户 
中 应 该 减 去 10 元 ， 同 时 ， 员 工 账 户 中 应 该 增加 10 元 。 这 两 个 操作 必须 
同时 完成 ， 或 者 同时 不 完成 。 


目 和 完 ， 让 我 们 看 一 下 主 画 数 中 是 如 何 局 动 一 个 内 存 事务 的 : 


01 public class STMDemo { 


02 public static ActorRef company=null; 

03 public static ActorRef employee=null; 

04 

05 public static void main(String[] args) throws Exception 


06 final ActorSystem system = 
ActorSystem.create("transactionDemo", ConfigFactory.load 
("samplehello.conf")); 

07 

company=system.actorOf(Props.create(CompanyActor.class), 
"company" ); 

08 

employee=system.actorOf(Props.create(EmployeeActor.class), 


"employee" ); 


09 

10 Timeout timeout = new Timeout(1, TimeUnit.SECONDS) ; 
11 

2 for(int Op 

13 company.tell(new Coordinated(i, timeout), 


ActorRef.noSender()); 


14 Thread.sleep(200) ; 
15 Integer companyCount = (Integer) Await.result( 
16 ask(company, "GetCount", timeout), 


timeout.duration()); 

17 Integer employeeCount = (Integer) Await.result( 
18 ask(employee, "GetCount", timeout), 
timeout.duration()); 

19 

20 System.out.printin("company 
count="+companyCount ) ， 

21 System.out.println( "employee 


count="+employeeCount ) ; 


22 System.out.println("=================") ; 
23 } 
24 } 


上 述 代 码 中 CompanyActor 和 EmployeeActor 分 别 用 于 管理 公司 账户 
和 雇员 账户 。 在 第 12 一 23 行 中 ， 我 们 生 试 进行 19 次 汇款 ， 第 一 次 汇款 
额度 为 1 元 ， 第 二 次 为 2 元 ， 依 此 类 推 ， 最 后 一 笔 汇 蒜 为 19 元 。 


在 第 13 行 ， 新 建 一 个 Coordinated 协 调 者 ， 并 且 将 这 个 协调 者 当做 
消息 发 送 给 company。 当 company 收 到 这 个 协调 者 消息 后 ， 上 自动 成 为 这 
个 事务 的 第 一 个 成 员 。 


第 15~18 行 询问 公司 账户 和 雇员 账户 的 当前 余额 ， 并 在 第 20~21 
行进 行 输出 。 


下 面 是 代表 公司 账户 的 Actor: 


01 public class CompanyActor extends UntypedActor { 


02 private Ref.View< Integer> count = STM.newRef (100); 

03 

04 @Override 

05 public void onReceive(Object msg) { 

06 if (msg instanceof Coordinated) { 

07 final Coordinated c=(Coordinated)msg; 

08 final int downCount=(Integer )c.getMessage(); 

09 STMDemo .employee.tell(c.coordinate(downCount), 


getSelf()); 


10 try{ 


11 c.atomic(new Runnable() { 

12 @Override 

13 public void run() { 

14 if (count.get()<downCount ) { 

15 throw new RuntimeException("less 


than "+downCount); 


16 } 

17 STM.increment(count, -downCount); 
18 } 

19 P), 

20 }catch(Exception e){ 

21 e.printStackTrace(); 

22 } 

23 

24 yelse if ("GetCount".equals(msg)) { 

25 getSender().tell(count.get(), getSelf()); 
26 telse{ 

27 unhandled(msg); 

28 } 

29 } 

30 } 


在 CompanyActor 中 ， 首 先 判断 接收 的 msg 是 否 是 Coordinated。 如 
果 是 Coordinated， 则 表示 这 是 一 个 新 事务 的 开始 。 在 第 8 行 ， 获 得 事务 
的 参数 也 束 是 需要 转账 的 金额 。 授 着 在 第 9 行 ， 将 调用 


Coordinated.coordinate() 方 法 ， 将 employee 也 加 入 到 当前 事务 中 ， 这 样 
这 个 事务 中 就 有 两 个 参与 者 了 。 


第 11 行 ， 调 用 了 Coordinated.atomic() 定 义 了 原子 执行 块 作为 这 个 
事务 的 一 部 分 。 在 这 个 执行 块 中 ， 对 公司 账户 进行 余额 调整 (第 17 
J) 。 但 是 当 汇 款额 度 大 于 可 用 余额 时 ， 就 会 抛 出 异常 ， 宣 告 失 败 。 


第 25 行 用 于 处 理 GetCount 消 息 ， 返 回 当 前 账户 余额 。 
作为 转账 接收 方 的 雇员 账户 如 下 : 


01 public class EmployeeActor extends UntypedActor { 


02 private Ref.View< Integer> count = STM.newRef (50); 
03 

04 @Override 

05 public void onReceive(Object msg) { 

06 if (msg instanceof Coordinated) { 

07 final Coordinated c = (Coordinated) msg; 

08 final int downCount = (Integer) c.getMessage(); 
09 try { 

10 c.atomic(new Runnable() { 

11 @Override 

12 public void run() { 

13 STM.increment(count, downCount); 
14 } 

15 }); 

16 } catch (Exception e) { 


I7 } 


18 } else if ("GetCount".equals(msg)) { 


19 getSender().tell(count.get(), getSelf()); 
20 } else { 

21 unhandled(msg) ; 

22 } 

23 } 

24 } 


上 述 代码 第 2 行 ， 设 置 雇员 账户 初始 金额 是 50 元 。 第 6 行 ， 判 断 消 
息 是 否 为 Coordinated， 如 果 是 Coordinated， 则 当前 Actor 会 自动 加 入 
Coordinated 指 定 的 事务 。 第 10 行 ， 定义 原子 控 作 ， 在 这 个 操作 中 将 修 
改 雇员 账户 余额 。 在 这 里 ， 我 们 并 没有 给 出 异常 情况 的 判断 ， 只 要 接 
收 到 转 入 金额 ， 一 律 将 其 增加 到 雇员 账户 中 。 


大 家 可 能 就 会 产生 疑问 ， 如 果 在 公司 账户 中 由 于 余额 不 足 而 导致 
转账 失败 了 ， 那 在 这 个 雇员 账户 中 不 还 古 正 常 增加 了 金额 吗 ? FRSA 
征 钱 多 出 来 了 ? 


不 过 这 个 担心 是 完全 多 余 的 。 因 为 在 这 里 ， 两 个 Actor 都 已 经 加 入 
到 同一 个 协调 事务 Coordinated 中 了 ， 因 此 当 公 司 账户 出 现 异 第 后 ， 雇 
DIRA NRA A ER ° 


执行 上 述 程序 ， 部 分 输出 如 下 : 


company count=85 
employee count=65 


java.lang.RuntimeException: less than 14 
company count=9 


employee count=141 


java.lang.RuntimeException: less than 19 


省 略 堆栈 信息 实在 太 多 了 


at 
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinwork 
erThread. java:107) 
company count=9 


employee count=141 


可 以 看 到 ， 无 论 转 账 操 作 是 否 成 功 ， 公 司 账户 和 雇员 账户 的 金额 
总 是 一 致 的 。 当 转账 失败 时 ， 雇 员 账 户 的 余额 并 不 会 增加 。 这 束 征 软 
件 事 务 内 存 的 作用 。 


7.13 一 个 有 趣 的 例子 ， 并 发 粒子 
群 的 实现 


粒子 群 算法 (PSO) 是 一 种 进化 算法 。 它 与 大 名 办 办 的 遗传 算法 
非常 类 似 ， 可 以 用 来 解决 一 些 优化 问题 。 大 家 知道 ， 一 些 优化 问题 
(比如 旅行 商 问 题 TSP) 都 属于 NP 问题 。 它 们 的 时 间 复 洒 度 可 能 会 达 
到 O(n1) 或 者 0(2”)， 这 种 在 多 项 式 时 间 内 不 可 解 的 问题 总 是 会 让 人 望 而 
生 县 。 而 以 PSO 算 法 为 代表 的 进化 计算 ， 往 往 可 以 将 这 些 NP 问 题 ， 转 
变 为 一 个 多 项 式 问 题 。 但 这 种 转变 是 有 代价 的 ， 进 化 算法 往往 都 不 保 
证 你 可 以 从 结果 中 得 到 最 优 解 。 我 这 么 说 ， 也 许 束 有 人 会 加 了 ， 这 个 
算法 都 不 能 保证 得 到 最 优 解 ， 那 有 什么 用 呢 ? 其 实 ， 在 生活 中 的 很 多 
场景 下 ， 并 不 是 特别 需要 最 优 解 ， 我 们 更 加 希望 得 到 的 古 一 个 满意 
解 。 比 如 说 ， 去 水 果 店 买 西瓜 ， 店 里 可 能 放 着 一 大 堆 西瓜 ， 每 个 人 都 
想 挑 一 个 最 好 的 。 但 你 想 拿 到 最 好 的 那个 西瓜 必须 得 挨个 检查 过 去 ， 
并 且 还 得 认真 做 好 记录 才 行 。 我 相信 ， 没 有 一 个 人 会 这 么 买 西 瓜 ， 因 
为 成 本 太 高 了 。 对 于 大 部 分 人 来 说 ， 更 倾 问 于 在 表面 上 挑 几 个 顺眼 的 
看 看 ， 如 果 还 过 得 去 ， 也 就 下 手 了 。 这 也 束 是 说 只 要 这 个 结果 不 要 差 
得 太 离谱 就 行 了 。 


既然 最 优 的 方案 很 难得 到 ， 那 么 我 们 束 想 办 法 以 很 低 的 成 本 获得 
一 个 还 算 过 得 去 的 方案 ， 也 不 失 为 一 计 民 策 。 在 后 面 给 出 的 小 案例 中 
大 家 也 可 以 看 到 ， 在 很 多 情况 下 ， 虽 然 进化 算法 无 法 让 你 获得 最 优 
解 ， 也 无 法 证 明 它 得 到 的 解 与 最 优 解 到 发 有 多 少 差距 ， 但 实际 中 ， 通 
过 进化 算法 搜索 到 的 满意 解 很 可 能 与 最 优 解 已 经 非常 接近 了 。 


7.13.1 什么 是 粒子 群 算法 


粒子 群 优化 算法 (PSO) 是 一 种 进化 计算 技术 ， 最 早 由 Kenny 与 
Eberhart 于 1995 年 提出 。 它 源 于 对 乌 群 捕食 行为 的 研究 ， 与 遗传 算法 相 
似 ， 是 一 种 基于 迭代 的 优化 算法 ， 广 泛 应 用 于 函数 优化 和 神经 网 络 训 
练 等 方面 。 与 遗传 算法 相 比 ，PSO 算 法 的 实现 简单 得 多 ， 参 数 配 置 也 
相对 较 少 ， 对 使 用 人 员 的 经 验 要 求 不 高 ， 因 此 更 加 易于 实际 工程 应 
用 o 


从 日 党 生活 的 观察 中 可 以 知道 ， 乌 类 的 葛 食 往往 会 表现 成 群体 特 
性 。 如 采 在 地 上 有 一 人 小报 食物 ， 那 么 马 群 很 可 能 吏 会 聚集 在 这 一 堆 食 
物 芝 边 。 如 果 其 中 一 只 小 乌 发 现 了 另外 一 堆 更 丰盛 的 食物 ， 那 它 可 能 
会 离 群 飞 问 更 丰盛 的 食物 ， 而 这 有 可 能 融 动 整个 乌 群 一 起 飞 回 新 的 地 
上 护 。 当 然 了 ， 在 整个 种 群 中 ， 难 免 会 出 现 几 只 特别 有 “个 性 ”的 小 马 ， 
它们 不 喜欢 太 热 闹 的 地 方 ， 当 整个 种 群 迁移 时 ， 它 们 不 会 跟着 种 群 
走 ， 或 者 目 己 散 步 ， 或 者 目 行 游荡 。 


粒子 群 算法 正 是 对 上 述 过 程 的 模拟 。 在 程序 中 ， 我 们 可 以 模拟 大 
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着 食物 越 征 丰 盛 ， 因 此 ， 模 拟 的 小 乌 会 从 目 己 的 位 置 出 发 以 一 定 的 速 
度 问 最 优点 的 方 癌 移动。 在 移动 过 程 中 ， 任 何 一 只 小 乌 都 有 可 能 发 现 
更 好 的 解 ， 这 又 会 进一步 影响 群体 的 行为 。 整 这样 如 此 反复 迭代 ， 最 
终 ， 将 得 到 一 个 不 错 的 答案 。 


7.13.2 ”粒子 群 算 法 的 计算 过 程 


粒子 群 算法 的 大 体 步 又 如 下 : 


1. 初始 化 所 有 粒子 ， 粒 子 的 位 置 随机 生成 。 计 算 每 个 粒子 当前 的 
适应 度 ， 并 将 此 设 为 当前 粒子 的 个 体 最 优 值 〈 记 为 pBest) 。 

2. 所 有 粒子 将 自己 的 个 体 最 优 值 发 送 给 管理 者 Master。Master 获 
得 所 有 粒子 的 信息 后 ， 筛 选 出 全 局 最 优 的 解 ( 记 为 gBest) 。 

3. Master 将 gBest 通 知 所 有 粒子 ， 所 有 粒子 便 知 道 全 局 最 优点 的 位 
置 o 

4. 接着 ， 所 有 粒子 根据 目 己 的 pPBest 和 全 局 gBest， 更 新 目 己 的 速 
度 ， 在 有 了 速度 后 ， 再 更 新 自己 的 位 置 。 


Vi¢1=CoXrand()xv;, +c, xrand()(pbest,—x,)+c5xrand()x(gbest;,—x;,) 


Xk+1—XkT Vk+1 
其 中 ，rand0O) 落 数 产生 一 个 0，1 之 间 的 随即 数 。co=1，c1=2， 
c=2，k 表 示 进 化 的 代数 。w 表示 当前 速度 ，pbest, 和 gbest ,表示 
个 体 最 优 解 和 全 局 最 优 解 。 当 然 ， 对 于 每 一 个 维度 上 的 速度 分 
量 ， 我 们 可 以 为 它 限 定 一 个 最 大 值 。 确 保 * 小 乌 ” 不 会 飞 得 太 
快 ， 错 过 了 重要 的 信息 。 

5. 如 有 果 粒 子 产 生 了 新 的 个 体 最 优点 ， 则 发 送 给 Master， 在 此 ， 转 
到 步骤 2。 


整体 过 程 的 示意 图 如 图 7.2 所 示 。 
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图 7-2 PSO 算法 示意 图 


从 这 个 计算 步 又 中 可 以 看 到 ， 计 算 过 程 拥有 一 定 的 随机 性 。 但 由 
于 我 们 可 以 启用 大 量 的 例子 ， 因 此 其 计算 效果 在 统计 学 意义 上 是 稳定 
的 。 在 这 个 标准 的 粒子 群 算 法 中 ， 由 于 所 有 粒子 都 会 加 全 局 最 优 靠 
拢 ， 因 此 ， 其 跳出 局 部 最 优 的 能 力 并 不 算 太 强 。 因 此 ， 我 们 也 可 以 想 
办 法 对 标准 的 粒子 群 算法 进行 一 些 合理 的 改进 。 比 如 ， 人 允许 各 个 粒子 
随机 移动 ， 甚 至 逆 同 移动 来 试图 突破 局 部 最 优 。 在 这 里 为 简单 起 见 ， 
我 不 打算 做 这 些 复 杂 的 实现 。 


7.13.3 ”粒子 群 算法 能 做 什么 


粒子 群 算法 能 为 我 们 做 些 什么 呢 ? 它 应 用 最 多 的 场景 是 进行 最 优 
化 计算 。 实 际 上 ， 以 粒子 群 算法 为 代表 的 进化 计算 ， 可 以 说 是 最 优化 
方法 中 的 通用 方法 。 几 乎 一 切 最 优化 问题 都 可 以 通过 这 种 随机 搜索 的 
模式 解决 ， 其 成 本 低 、 难 度 小 、 效 采 好 ， 因 此 掺 受 欢迎 。 


下 面 ， 束 让 我 们 来 探讨 一 个 典型 的 优化 问题 : 


假设 现在 有 400 万 资金 ， 要 求 4 年 内 使 用 完 。 若 在 第 1 年 使 用 x 万 
元 ， 则 可 以 得 到 效益 Vx 万 元 (效益 不 能 再 使 用 ) ， 当 年 不 用 的 资金 
可 存 入 银行 ， 年 利率 为 10%。 党 试制 订 出 资金 的 使 用 规划 ， 使 4 年 效益 
之 和 最 大 。 


很 明显 ， 对 于 这 类 问题 ， 不 同 的 方案 得 到 的 结 采 可 能 会 有 很 大 的 
异 。 比 如 ， 阁 第 一 年 把 400 万 元 全 部 用 完 ， 则 忌 效 益 为 Y400 =20 万 
; 若 前 3 年 均 不 用 而 存 入 银行 ， 第 4 年 把 本 金 和 利息 全 部 用 完 ， 则 总 
改 益 为 \/400*1.1 =23.07 万 元 ， 显 然 优 于 第 一 种 方案 。 
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如 果 我 们 将 此 问题 转 为 一 般 化 的 优化 问题 ， 则 可 以 得 到 以 下 方程 
组 ， 如 图 7.3 所 示 。 
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图 7.3 ”一 般 化 的 约束 问题 


其 中 ，xl、x2、Xx3、x4 分 别 表示 第 1、2、3、4 年 使 用 的 资金 。 使 
用 拉 格 朗 日 乘 子 法 对 此 方程 组 进行 求解 ， 可 以 得 到 第 一 年 使 用 86.19 万 
元 、 第 2 年 使 用 104.29 万 元 ， 第 3 年 使 用 126.19 万 元 ， 第 4 年 使 用 152.69 
万 元 为 这 个 问题 的 最 优 解 ， 此 时 总 效益 达 43.09 万 元 。 


由 于 求解 过 程 过 于 复杂 ， 使 用 拉 格 明日 乘 子 法 时 ， 需 要 对 爷 后 12 
个 未 知 数 和 方程 进行 联 立 求解 ， 比 较 难 以 实现 。 由 于 求解 过 程 与 我 们 
讨论 的 主题 无 关 ， 所 以 在 这 里 不 再 给 


对 于 类 似 的 优化 问题 ， 正 古 粒 子 群 算法 的 涉猎 范围 。 当 使 用 粒子 
群 算法 时 ， 我 们 可 以 先 随机 给 出 大 和 干 个 满足 提交 的 闹 金 规划 方案 。 接 
着 ， 根 据 粒子 群 的 演化 公式 ， 不 断 调整 各 个 粒子 的 位 置 (粒子 的 每 一 
个 位 置 代表 一 套 方案 ) ， 逐 步 探索 更 优 的 方案 。 


7.13.4 “使 用 Akka 实 现 粒 子 群 


现在 ， 我 们 已 经 知道 粒子 群 的 原理 ， 并 且 有 了 一 个 较为 复杂 的 优 
化 问题 等 竺 我 们 求解 。 接 下 来 ， 束 需要 开动 脑筋 ， 使 用 Akka 来 实现 一 
个 简单 的 粒子 群 ， 来 解决 这 个 优化 问题 了 。 


使 用 Actor 的 模式 与 粒子 群 算法 之 间 有 着 天 生 切 合 度 。 粒 子 群 算法 
由 于 涉及 到 多 个 甚至 是 极其 大 量 的 粒子 参与 运算 ， 因 此 它 隐 含 着 并 行 
计算 的 模式 。 其 次 ， 从 直观 上 我 们 也 可 以 知道 ， 粒 子 群 算法 的 求解 精 
度 或 者 说 求解 的 质量 ， 与 参与 运算 的 粒子 有 着 直接 的 关系 。 很 显然 ， 
参与 运算 的 粒子 数量 越 多 ， 得 到 的 解 目 然 也 束 越 精确 。 


如 果 我 们 使 用 传统 的 多 线程 方式 实现 粒子 群 ， 一 个 最 大 的 问题 束 
征 线程 的 数量 可 能 是 非常 有 限 的 。 在 当前 这 种 应 用 场景 中 ， 我 们 希望 
可 以 拥有 数 万 ， 基 至 数 十 万 的 粒子 ， 以 提高 计算 精度 ， 但 众所周知 ， 
在 一 台 计 算 机 上 运行 数 万 个 线程 基本 是 不 可 能 的 ， 融 算 可 以 ， 系 统 的 
性 能 也 会 大 打折 扣 。 因 此 ， 使 用 多 线程 的 模型 无 法 很 好 地 和 粒子 群 的 
实现 相 融 合 。 


但 Akka 的 Actor 的 模型 则 不 同 。 由 于 多 个 Actor 可 以 复 用 一 个 线 
程 ， 而 Actor 本 吴 作为 轻 量 级 的 并 发 执行 单元 可 以 有 极其 大 量 的 存在 。 
因此 ， 我 们 就 可 以 使 用 Actor 来 模拟 整个 粒子 群 计算 的 场景 。 下 面 就 让 
我 们 仔细 看 一 下 系统 的 实现 。 


首先 ， 我 们 需要 两 个 表示 pBest 和 gBest 的 消息 类 型 ， 用 于 在 多 个 
Actor 之 间 传 递 个 体 最 优 和 全 局 最 优 。 


01 public final class GBestMsg { 


02 final PsoValue value; 

03 public GBestMsg(PsoValue v){ 
04 value=v; 

05 } 

06 public PsoValue getValue() { 
07 return value; 

08 } 

09 } 

10 


11 public final class PBestMsg { 


12 final PsoValue value; 

13 public PBestMsg(PsoValue v){ 
14 value=v; 

15 } 

16 

17 public PsoValue getValue() { 
18 return value; 


19 } 


21 public String toString(){ 
22 return value.toString(); 
23 } 

24 } 


上 述 代码 中 ，GBestMsg (代码 第 1 行 ) 表示 携带 全 局 最 优 解 的 消 
kc i PBestMse (代码 第 11 行 ) 表示 携带 个 体 最 优 的 消息 。 它 们 都 使 
用 PsoValue 来 表示 一 个 可 行 的 解 。 


在 PsoValue 中 ， 主 要 包括 两 个 信息 ， 第 一 是 表示 投资 规划 的 方 
即 每 一 年 分 别 需 要 投资 多 少 钱 ; 第 二 是 这 个 投资 方案 的 总 收益 


01 public final class PsoValue { 


02 final double value; 

03 final List<Double> x; 

04 public PsoValue(double v,List<Double> x){ 
05 value=v; 

06 List<Double> b=new ArrayList <Double> (5); 
07 b.addAll(x); 

08 this.x=Collections.unmodifiableList(b); 
09 } 

10 public double getValue(){ 

eas return value; 

12 } 

13 public List<Double> getX(){ 

14 return x; 


15 } 


17 public String toString(){ 

18 StringBuffer sb=new StringBuffer(); 

19 sb.append("value:").append(value).append("\n") 
20 .append(x.toString()); 

21 return sb.toString(); 

22 } 

23>} 


上 述 代 码 中 ， 数 组 x 中 ，x[1、x[2]、x[3]、x[4] 分 别 表示 第 1 年 、 

第 2 年 、 第 3 年 和 第 4 年 的 投资 额 。 这 里 为 了 方便 起 见 ， 我 忽略 了 x[0] 

( 它 在 我 们 的 程序 中 是 没有 作用 的 ) 。 成 员 变 量 value 表 示 这 组 投资 方 
案 的 收益 值 。 


此 ， 根 据 需 求 x 与 value 之 间 的 关系 如 下 代码 所 示 : 


1 public class Fitness { 

2 public static double fitness(List<Double> x){ 
3 double sum=0; 

4 for(int i=1;i<x.size();i++){ 

5 sum+=Math.sqrt(x.get(i)); 

6 J 

7 return sum; 

8 t 

9 } 


EIRAB X A fitness KHOR E T A ERAREMA ° EM 
上 度 也 就 是 投资 的 收益 ， 我 们 目 然 应 该 更 倾 癌 于 选择 适应 度 更 高 的 投资 
方案 "在 这 里 适应 度 =/xl + Vx2 + Vx3 + x4 ° 


有 了 这 些 基 础 工具 ， 我 们 就 可 以 来 实现 简单 的 粒子 (这 里 我 把 它 
叫 作 Bird) T ° 
对 于 基本 粒子 ， 我 们 需要 定义 以 下 成 员 变 量 : 


1 public class Bird extends UntypedActor { 
2 private final LoggingAdapter log = 


Logging.getLogger(getContext().system(), this); 


3 private PsoValue pBest=null; 

4 private PsoValue gBest=null; 

5 private List<Double> velocity =new ArrayList <Double> 
(5); 

6 private List<Double> x =new ArrayList <Double> (5); 

7 private Random r = new Random()j; 


上 述 代 码 中 ，pBest 和 gBest 分 别 表示 个 体 最 优 和 全 局 最 优 ， 
velocity 表 示 粒 子 在 各 个 维度 上 的 速度 (在 当前 案例 中 ， 每 一 年 的 投资 
额 就 可 以 认为 是 一 个 维度 ， 因 此 系统 有 4 个 维度 ) 。x 表 示 投 资方 案 ， 
即 每 一 年 的 投资 额 。 由 于 在 粒子 群 算法 中 ， 需 要 使 用 随机 数 ， 因 此 ， 
HE MT re 


当 一 个 粒子 被 创建 时 ， 我 们 需要 初始 化 粒子 的 当前 位 置 。 粒 子 的 
每 一 个 位 置 都 代表 一 个 投资 方案 ， 下 面 的 代码 展示 了 粒子 的 初始 化 逻 
辑 : 


01 @Override 


02 public void preStart(){ 


03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
i 
18 
19 
20 
2i 
22 
23 
24 
25 
26 
27 


for(int i=0;i<5;i++){ 
velocity.add(Double.NEGATIVE_INFINITY) ; 
x.add(Double.NEGATIVE_INFINITY); 

i 

//X1<=400 


x.set(1, (double)r.nextInt(401) ); 


//X2<=440-1.1*x1 
double max=400-1.1*x.get(1); 
if (max <0)max=0; 


x.set(2, r.nextDouble()*max); 


//X3<=484-1.21*x1-1.1*x2 
max=484-1.21*x.get(1)-1.1*x.get(2); 
if (max <=0)max=0; 


x.set(3, r.nextDouble()*max); 


//x4<= 532.4-1.331*x1-1.21*x2-1.1*x3 
max=532.4-1.331*x.get(1)-1.21*x.get(2)-1.1*x.get(3); 
if (max <=0)max=0; 


x.set(4, r.nextDouble()*max); 


double newFit=Fitness.fitness(x); 
pBest=new PsoValue(newFit, x); 


PBestMsg pBestMsg=new PBestMsg(pBest)/; 


28 ActorSelection selection = 
getContext().actorSelection("/user/masterbird"); 

29 selection.tell(pBestMsg, getSelf()); 

30 } 


由 于 在 当前 案例 中 ， 每 一 年 的 投资 额度 是 有 条 件 约束 的 ， 比 如 第 
一 年 的 投资 额 不 能 超过 400 万 〈 第 7~8 行 ) ， 而 第 2 年 的 投资 上 限 是 440 
万 〈 假 设 第 一 年 全 部 存 银行 ， 代 码 第 10~13 行 ) ， 依 此 类 推 。 粒 子 初 
台 化 时 ， 随 机 生成 一 组 满足 基本 约束 条 件 的 投资 组 合 ， 并 计算 它 的 适 
应 度 〈 第 25 行 ) 。 初 始 的 投资 方案 自然 也 就 作为 当前 的 个 体 最 优 ， 并 
发 送 给 Master (第 29 行 ) ° 


当 Master 计 算出 当前 全 局 最 优 后 ， 会 将 全 局 最 优 发 送 给 每 一 个 粒 
子 ， 粒 子 根据 全 局 最 优 更 新 目 己 的 运行 速度 ， 并 更 狐 目 己 的 速度 以 及 
当前 位 置 。 


01 @Override 


02 public void onReceive(Object msg) { 


03 if (msg instanceof GBestMsg) { 

04 gBest=((GBestMsg) msg).getValue(); 
05 // 更 新 速度 

06 for(int 1=1;i<velocity.size();i++){ 
07 updateVelocity(1); 

08 } 

09 // 更 新 位 置 

10 for(int 1=1;1<x.size();i++){ 

11 updateX(i); 


12 1 


13 validatex(); 


14 double newFit=Fitness.fitness(x); 

15 if (newFit > pBest.value){ 

16 pBest=new PsoValue(newFit,x); 

17 PBestMsg pBestMsg=new PBestMsg(pBest); 
18 getSender().tell(pBestMsg, getSelf()); 
19 } 

20 } 

21 else{ 

22 unhandled(msg); 

23 } 

24 } 


上 述 代 码 中 ， 粒 子 接收 到 了 全 局 最 优 〈 代 码 第 4 行 ) ， 接 着 根据 粒 
子 群 的 标准 公式 更 新 自己 的 速度 (第 6~8 行 ) 。 接 着 ， 根 据 速度 ， 更 
新 目 己 的 位 置 (第 10~~12 行 ) 。 由 于 当前 问题 是 有 约束 的 ， 也 就 是 说 
解 空 间 并 不 是 随意 的 。 粒 子 很 可 能 在 更 新 位 置 后 ， 跑 出 了 合理 的 苍 转 
之 外 ， 因 此 ， 还 有 必要 进行 有 效 性 检查 (第 13 行 ) ° 


在 更 新 完成 后 ， 就 可 以 计算 新 位 置 的 适应 度 ， 如 果 产 生 了 新 的 个 
体 最 优 ， 就 将 其 发 送 给 Master (第 15~19 行 ) 。 


在 当前 案例 中 ， 速 度 和 位 置 的 更 新 是 依据 标准 的 粒子 群 实现 ， 如 
T 


01 public double updateVelocity(int i){ 
02 double v= Math.random()*velocity.get(i) 
03 +2*Math.random( )*(pBest.getX().get(i)-x.get(i)) 


04 +2*Math.random( )*(gBest.getX().get(i)-x.get(i)); 


05 v=v>0? Math.min(v, 5): Math.max(v, -5); 
06 velocity.set(i, v); 

07 return V; 

08 } 

09 


10 public double updateX(int i){ 


11 double newX=x.get(i)+velocity.get(i); 
12 x.set(i, newX); 

13 return newX; 

14 } 


上 述 代码 中 updateVelocity0 和 updateX0 分 别 更 新 了 粒子 的 速度 和 
位 置 。 位 置 的 更 新 依赖 于 当前 的 速度 (第 11 行 ) 。 


由 于 每 一 年 的 投资 都 是 有 限额 的 ， 因 此 ， 要 避免 粒子 跑 到 合理 空 
间 之 外 ， 下 面 的 代码 强制 将 粒子 约束 中 合理 的 区 间 中 。 


01 public void validateX(){ 


02 if(x.get(1)>400){ 

03 x.set(1, (double)r.nextInt(401)); 
04 } 

05 

06 /1X2 

07 double max=400-1.1*x.get(1); 

08 if(x.get(2)>max || x.get(2)<0){ 

09 x.set(2, r.nextDouble()*max); 


10 } 


11 //X3 


12 max=484-1.21*x.get(1)-1.1*x.get(2); 

LS if(x.get(3)>max || x.get(3)<0){ 

14 x.set(3, r.nextDouble()*max); 

15 } 

16 /1X4 

17 max=532.4-1.331*x.get(1)-1.21*x.get(2)-1.1*x.get(3); 
18 if(x.get(4)>max || x.get(4)<0){ 

19 x.set(4, r.nextDouble()*max); 

20 } 

21 } 


上 述 代 码 分 别 对 x1、x2、x3、x4 进 行 约 束 ， 一 旦 发 现 粒子 跑 出 了 
定义 范围 就 将 它 进行 随机 化 。 


此 外 ， 我 们 还 需要 一 只 MasterBird， 用 于 管理 和 通知 全 局 最 优 。 


01 public class MasterBird extends UntypedActor { 
02 private final LoggingAdapter log = 


Logging.getLogger(getContext().system(), this); 


03 private PsoValue gBest=null; 

04 

05 @Override 

06 public void onReceive(Object msg) { 

07 if (msg instanceof PBestMsg) { 

08 PsoValue pBest = ((PBestMsg) msg).getValue(); 
09 if(gBest==null || gBest.value < pBest.value){ 


10 // 更 狐 全 局 最 优 ， 通 知 所 有 粒子 


11 System.out.printin(msgt+"\n"); 

12 gBest=pBest, 

13 ActorSelection selection = 
getContext().actorSelection("/user/bird_*"); 

14 selection.tell(new GBestMsg(gBest), 
getSelf()); 

15 } 

16 } 

17 elsef{ 


18 unhandled(msg); 


上 述 代码 定义 了 MasterBird。 当 它 收 到 一 个 个 体 最 优 的 解 时 ， 会 
将 其 与 全 局 最 优 进行 比较 ， 如 采 产 生 了 新 的 全 局 最 优 ， 束 更 新 这 个 全 
局 最 优 并 通知 所 有 的 粒子 (第 12~~14 行 ) ° 


FT, PIE A SHAE AOR © PB Bie KZ: 


01 public class PSOMain { 


02 public static final int BIRD_COUNT = 100000; 

03 public static void main(String[] args) { 

04 ActorSystem system = ActorSystem 

05 .create("psoSystem", 


ConfigFactory.load("samplehello.conf")); 
06 system.actorOf(Props.create(MasterBird.class), 


"masterbird"); 


07 for (int i = 0; i < BIRD_COUNT; i++) { 


08 system.actorOf(Props.create(Bird.class), "bird_" 


上 述 代 码 定 义 了 粒子 总 数 ， 这 里 是 10 万 个 粒子 。 接 着 创建 一 个 
MasterBird Actor 〈 第 6 行 ) ， 和 10 万 个 bird 〈 第 7~-9 行 ) 。 


执行 上 述 代 码 ， 运 行 一 小 段 时 间 ， 你 避 ® 可 以 得 到 如 下 输出 (截取 


Bar) 


OK 


value: 36.15412875487459 

[-Infinity, 168.0, 18. 786423873345715, 102 .1742923174793, 
76.5657638235272 | 

value: 37.88452477135976 

[-Infinity, 64.0, 87 .66774733441137, 37 .976681047619195, 
206.17791816445362 | 


value: 42 .240797528048176 
[-Infinity, 113.0, 42.37168995110633, 141.70570102409184, 
174.16812834843475 | 


value: 43 .01934824083668 
[-Infinity, 76.0, 112 .89557345993592, 133.29270155682005, 
147 .16289926594942 | 


上 述 输 出 表示 ， 当 粒子 群 随机 初始 化 时 ， 最 优 解 为 36.15 万 元 ， 但 
随 着 粒子 的 搜索 ， 这 个 投 痪 方案 被 逐步 优化 ， 由 37.88 万 一 直上 升 到 
43.02 万 元 。 根 据 我 们 前 面 的 求解 ， 我 们 知道 这 个 投资 方案 的 最 优 结 
征 43.09 万 元 ， 可 以 看 到 ， 粒 子 群 的 搜索 结 有 末 和 全 局 最 优 已 经 非常 接近 
Te 


当然 了 ， 由 于 粒子 群 算法 的 随机 性 ， 每 次 执行 结果 可 能 并 不 一 
样 ， 这 意味 着 有 时 候 ， 你 可 能 会 求 得 更 好 的 解 ， 或 者 得 到 一 个 稍 老 一 
些 的 解 ， 但 其 偏差 不 会 相差 太 远 。 


7.14 参考 文献 


。 Akka 官 方 文档 
o http://doc.akka.io/docs/akka/2.3.7/java.html 


。 有 关 最 优化 方法 的 介绍 


o KRAUT) FAA DEHE CRE 
e Nobody Needs Reliable Messaging 


o http://www.infoq.com/articles/no-reliable-messaging 


第 8 章 ”并 行程 序 调试 


并 行程 序 调试 要 比 串 行程 序 复 杂 得 多 ， 但 笠 运 的 是 ， 现 代 IDE 开 
发 环境 可 以 在 一 定 程度 上 缓 建 并 发 程序 调试 的 难度 。 在 本 章 中 ， 我 想 
简单 介绍 一 下 有 关 并 行程 序 调试 的 一 些 技巧 和 经 验 。 


8.1 ”准备 实验 样本 


为 了 方便 讲解 ， 我 们 定义 一 个 简单 的 类 ， 作 为 实验 样本 : 


01 public class UnsafeArrayList { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
‘lal 
ie 
13 


static ArrayList al=new ArrayList(); 
static class AddTask implements Runnable{ 
@Override 
public void run() { 
try { 
Thread.sleep(100) ; 
} catch (InterruptedException e) {} 
for(int i=0;1<1000000; i++) 
al.add(new Object()); 


public static void main(String[] args) 


InterruptedException { 


14 
15 
16 
17 
18 
19 
20 


Thread ti=new Thread(new AddTask(),"t1i"); 

Thread t2=new Thread(new AddTask(),"t2"); 

ti.start(); 

t2.start(); 

Thread t3=new Thread(new Runnable(){ 
@Override 


public void run() { 


throws 


21 while(true) { 
22 try { 
23 Thread.sleep(1000); 


24 } catch (InterruptedException e) {} 


26 } 
27 PAD 
28 t3.start(); 


在 这 里 ， 我 使 用 的 JDK 版 本 为 JDK8u5 ° 


上 述 代 码 是 在 多 线程 下 访问 ArrayList， 因 此 ， 是 错误 的 写法 。 在 
这 里 ， 我 们 将 使 用 调试 ， 重 现 这 个 错误 。 


8.2 ERE 


在 正式 开始 之 前 ， 先 让 我 们 熟悉 一 下 Eclipse 的 调试 环境 。 当 你 使 
用 Eclipse 调试 Java 程 序 时 ， 当 程序 执行 到 断 点 处 ， 默 认 情 况 下 ， 当 前 
的 线程 就 会 被 挂 起 。 


图 8.1 显 示 了 在 ArrayList.add() 范 数 内 部 设置 了 一 个 断 点 : 


442- public boolean PEEKE e) { 

443 ensureCapacityInternal(size + 1); // Increments modCount!! 
444 elementData[size++] = 

445 return true; 

446 } 


图 8-1 将 断 点 设置 在 ArrayList.addO 内 


接着 ， 以 调试 方式 启动 上 面 的 代码 ， 可 以 看 到 ， 程 序 会 停留 在 系 
统 第 一 次 调用 ArrayListadd0 的 地 方 ， 如 图 8.2 所 示 。 


4 D] UnsafeArrayList [Java Application] 
4 & geym.conc.ch8.UnsafeArrayList at localhost:23564 
4 g@ Thread [main] (Suspended (breakpoint at line 443 in ArrayList) 

& owns: URLClassPath (id=23) 

& owns: Object (id=24) 

& owns: Object (id=25) 
ArrayList<E>.add(E) line: 443 
URLClassPath.getLoader(int) line: 344 
URLClassPath.getResource(String, boolean) line: 198 
URLClassLoader$1.runQ line: 364 
URLClassLoader$L.runQ line: 361 
AccessController.doPrivileged(PrivilegedExceptionAction<T>, AccessControlContext) line: not availa 
Launcher$ExtClassLoader(URLClassLoader).findClass(String) line: 360 
Launcher$ExtClassLoader(ClassLoader).loadClass(String, boolean) line: 424 
Launcher$AppClassLoader(ClassLoader).loadClass(String, boolean) line: 411 
Launcher$AppClassLoader.loadClass(String, boolean) line: 308 
Launcher$AppClassLoader(ClassLoader).loadClass(String) line: 357 


= 


LauncherHelper.checkAndLoadMain(boolean, int, String) line: 495 
p D:\tools\jdk8u5\bin\javaw.exe (2015 年 5 月 9 日 下 午 1:02:19) 


图 8.2” 断 点 阻止 了 程序 的 运行 


在 上 图 8.2 中 ， 可 以 看 到 主线 程 main 停 留 在 ArrayListadd0 中 ， 并 且 
显示 了 完整 的 调用 堆栈 。 但 很 不 邓 的 是 ， 其 实 我 们 对 主 函 数 并 没有 大 
大 兴趣 ， 因 为 这 些 都 是 JDK 内 部 的 代码 实现 。 目 前 ， 我 们 更 关心 的 是 
在 程序 中 t1 和 t2 线 程 对 ArrayList 的 调用 。 因 此 ， 我 们 会 更 希望 忽略 这 些 
无 天 的 调用 。 Re cee i 如 采 不 加 识别 地 
进行 断 点 设置 ， 对 系统 的 整个 调试 会 变 得 异常 痛 苗 。 那 么 应 该 怎么 处 
HEIE? 


依托 于 Eclipse 的 强大 功能 ， 我 们 很 容易 实现 这 点 。 我 们 可 以 为 这 
个 断 点 设置 一 些 额 外 属性 ， 如 图 8.3 所 示 。 


fa: aan l E Se are ee T r 


| © Toggle Breakpoint Ctrl+Shift+B 
| Disable Breakpoint Shift+Double Click 


i vV Show Line Numbers 


Folding 
Preferences... 
图 8.3 BEE RRE 


Ba Ber) 78 4a Be ES OY A E, AEE R PT R H PE 
所 条 件 是 当前 线程 而 不 是 主线 程 main， 如 图 8.4 所 示 ， 取 得 当前 线程 名 
称 ， 并 判断 是 否 为 主线 程 : 


'@} Properties for java.util ArrayList [I lline:443] - add) JE ae Do x 
|| Line Breakpoint 


Breakpoint Properties Fee E 
Filtering : 

Line Number: 443 

Member: add(E) 


v| Enabled 


|] Hit count: © Suspend thread © Suspend VM 
¥| Conditional @ Suspend when ‘true’ 


© Suspend when value changes 
<Choose a previously entered condition> 


(! (Thread. currentThread().getName().equals(“main")’ + 


图 8.4 ”设置 条 件 断 点 


基于 以 上 设置 ， 再 次 执行 调试 这 段 代码 ， 我 们 束 可 以 调试 tL 和 t2 
线程 了 ， 如 图 8.5 所 示 。 


4 O UnsafeArrayList Java Application] 
4 È geym.conc.ch8.UnsafeArrayList at localhost:64528 
4 og Thread [t2] (Suspended (breakpoint at line 443 in ArrayList)) 
= Arraylist<E>.add(E) line: 443 
= UnsafeArrayList$AddTask.run( line: 19 
三 Thread.run(Q line: 745 
4 g® Thread [t1] (Suspended (breakpoint at line 443 in ArrayList)) 


= ArrayList<E>.add(E) line: 443 
= UnsafeArrayList$AddTask.run( line: 19 
三 Thread.run(Q line: 745 
p® Thread [DestroyJavaVM] (Running) 
p® Thread [t3] (Running) 
pl D:\tools\jdk8u5\bin\javaw.exe (2015 年 5 月 9 日 下 午 5:14:25) 


图 8.5 ”被 中 断 的 tL 和 t2 


从 这 个 调试 窗口 中 可 以 看 到 ， 当 前 正在 执行 的 几 个 线程 ， 这 里 显 
示 了 t1、 世 和 t3。 由 于 t3 线 程 并 没有 使 用 ArrayList， 因 此 ， 它 处 于 


Running 状 态 ， 并 保持 一 直 执 行 。 而 tL 和 t2 两 个 线程 都 在 ArrayList.add() 
方法 中 被 挂 起 。 


如 上 图 8.5 所 示 ， 当 前 选中 的 是 2 线程 ， 如 果 我 们 进行 单 步 操作 ， 
那么 2 线程 束 会 执行 ， 而 t1 不 会 继续 执行 ， 除 非 ， 你 手工 选择 t1 并 进行 
相应 的 操作 。 


8.3 ” 挂 起 整个 虚拟 机 


在 这 里 ， 我 还 想 拓 一 个 比较 重要 的 功能 。 在 默认 情况 下 ， 当 断 点 
条 件 成 立时 ， 系 统 会 挂 起 相关 的 线程 ， 没 有 断 点 的 线程 会 继续 执行 。 
在 实际 环境 中 ， 那 些 还 在 继续 执行 的 线程 可 能 会 对 整个 调试 产生 不 利 
的 影响 。 为 此 ， 我 们 可 以 设置 断 点 类 型 为 挂 起 整个 Java 虚 拟 机 ， 而 不 
仅仅 是 挂 起 相关 线程 。 如 图 8.6 所 示 ， 改 变 这 个 断 点 的 类 型 : 


© Properties for java.util.ArrayList [line:443] - add(E) 


type filter text Line Breakpoint à iar 


Ronskpoint Propaction. Type: java.util. ArrayList 


Line Number: 443 
Member: add(E) 


Filtering 


[V] Enabled 


Hit count: Suspend thread] @ Suspend VM 


V] Conditional @ Suspend when ‘true’ Suspend when value changes 


| <Choose a previously entered condition> X | 


(! (Thread. currentThread().getName().equals(“main")’ - 


@ (aD a 
x 


图 8.6 ”设置 断 点 类 型 为 挂 起 整个 虚拟 机 


当然 ， 默 认 情 况 下 ， 调 试 右 只 会 挂 起 遇 到 断 点 的 线程 ， 如 果 你 希 
望 所 有 断 点 的 模式 都 挂 起 虚拟 机 而 不 是 挂 起 线程 ， 则 还 可 以 在 
Eclipse 的 全 局 配置 中 设置 ， 如 图 8.7 所 示 。 


type filter text 


> General 
> Ant 

> Data Management See ‘Run/Debug' for general debug settings. 

> Help Suspend Execution 

> Install/Update 三 [V] Suspend execution on uncaught exceptions 


General settings for Java Debugging. 


4 Java V] Suspend execution on compilation errors 


> Appearance 加 Suspend for breakpoints during evaluations 


> Build Path = [E] Open popup when suspended on exception 
Code Styl 
l j : T Default suspend policy for new breakpoints: [Suspend vm ~] 
> Compiler 
Default suspend policy for new watchpoints: [Sucpend Md 
> Editor 


> Installed JREs Hot Code Replace 
JUnit [V] Show error when hot code replace fails 


Properties Files Ec Show error when hot code replace is not supported 


è > Java EE dé [V] Show error when obsolete methods remain after hot code replace 
m r > : we ae 


~ 


图 8.7 设置 断 点 模式 行为 为 挂 起 虚拟 机 


在 挂 起 虚拟 机 模式 下 ， 程 序 进 入 断 点 后 的 状态 如 图 8.8 所 示 。 


4 DD UnsafeArrayList Java Application] 
4 有 geym.conc.ch8.UnsafeArrayList at localhost:65475 (Suspended) 
> gf Daemon System Thread [Attach Listener] (Suspended) 
> gi Daemon System Thread [Signal Dispatcher] (Suspended) 
> gi Daemon System Thread [Finalizer] (Suspended) 
> gi Daemon System Thread [Reference Handler] (Suspended) 
4 oP Thread [t1] (Suspended (breakpoint at line 443 in ArrayList)) 


|= ArrayList<E>.add{(E) line: 443 | 
= UnsafeArrayList$AddTask.run() line: 19 
= Thread.run(Q line: 745 
> g® Thread [t2] (Suspended) 
> 只 Thread [DestroyJavaVM] (Suspended) 
> g® Thread [t3] (Suspended) 
pol D:\tools\jdk8u5\bin\javaw.exe (2015 年 5 月 9 日 下 午 5:20:46) 


图 8.8 挂 起 虚拟 机 时 的 系统 状态 


可 以 看 到 ， 当 前 所 有 的 线程 全 部 处 于 挂 起 状态 ， 不 论 当 前 线程 是 
否 接 触 到 了 断 点 。 这 种 模式 可 以 排除 其 他 线程 对 被 调试 线程 的 干扰 。 
当然 ， 使 用 这 种 方法 有 时 候 会 引起 调试 器 或 者 虚拟 机 的 一 些 问 题 ， 导 
致 系统 不 能 正常 工作 。 


直接 执行 上 述 代 码 ， 很 可 能 抛 出 类 似 下 面 的 异 稼 : 


Exception in thread te 
java.lang.ArrayIndex0utOfBoundsException: 21079 
at java.util.ArrayList.add(ArrayList.java:444) 
at 
geym.conc.ch8.UnsafeArrayList$AddTask.run(UnsafeArrayList. java: 
19) 


at java.lang.Thread.run(Thread. java: 745) 


下 面 ， 束 让 我 们 用 单 步调 试 的 方法 ， 来 重 现 这 个 异常 吧 ! 


8.4 调试 进入 ArrayList 内 部 


首先 ， 我 们 需要 理解 ArrayList 的 工作 方式 。 在 ArrayList 初 始 化 
时 ， 默 认 会 分 配 10 个 数组 空间 。 当 数组 空间 消耗 完毕 后 ，ArrayList 残 
会 进行 自动 扩容 。 在 每 次 add0 操 作 时 ， 系 统 总 要 事先 检查 一 下 内 部 空 
间 是 否 满 足 所 需 的 大 小 ， 如 有 果 不 满 足 ， 束 会 扩容 ， 否 则 就 可 以 正常 添 
WICH ° 


多 线程 共同 访问 ArrayList 的 问题 在 于 : 在 ArrayList 容 量 快 用 完 时 
(只 有 1 个 可 用 空间 ) ， 如 果 两 个 线程 同时 进入 add0 函 数 ， 并 同时 判 
盯 认 为 系统 满足 继续 应 加 元 素 而 不 需要 扩容 ， 进 而 两 者 都 不 会 进行 扩 
容 操 作 。 之 后 ， 两 个 线程 先后 向 系统 写 入 自己 的 数据 ， 那 么 必然 有 一 
个 线程 会 将 数据 写 到 边界 外 ， 而 产生 这 个 
ArrayIndexOutOfBoundsException ° 


基于 上 壕 原 理 ， 我 们 在 ArrayList.add() 芳 数 中 设置 断 点 如 图 8.9 所 
ZN O 


Line Breakpoint 


Type: java.util. ArrayList 
Line Number: 443 
Member: add(E) 


V| Enabled 
Hit count: © Suspend thread Suspend VM 
v] Conditional @ Suspend when ‘true’ Suspend when value changes 


<Choose a previously entered condition> X 


((! (Thread. currentThread().getName().equals("main"))) < 
&& size== 9 


图 8.9_ ArrayListadd0 的 断 点 设置 


个 断 点 意味 着 在 非 主 线程 中 (这 里 就 是 t 和 t2 了 ) ， 当 进入 
如 果 当 前 ArrayList 的 容量 为 9 〈 当 前 的 最 大 容量 为 10) , 
则 触发 断 点 。 之 所 以 这 么 设置 ， 是 因为 当 容量 没有 饱和 时 ， 显 然 不 会 
发 生 这 个 ArrayIndexOutOfBoundsException 的 问题 ， 因 此 可 以 直接 忽略 
这 些 情况 。 


接着 ， 选 中 t1 线 程 ， 让 它 进行 容量 检查 ， 并 让 它 停止 在 追加 元 素 
的 语句 前 ， 如 图 8.10 所 示 。 


$S Debug X 4h Serve 
O UnsafeArrayList [Java Application] 
4 @& geym.conc.ch8.UnsafeArrayList at localhost:5732 
4 ¿® Thread [t2] (Suspended (breakpoint at line 443 in ArrayList)) 
= ArrayList<E>.add(E) line: 443 
= UnsafeArrayList$AddTask.run( line: 19 
= Thread.runQ line: 745 
4 ¿® Thread [t1] (Suspended) 
UnsateArraylist$Add : 
三 Thread.run0 line: 745 
pS Thread [t3] (Running) 
pÊ paes [pania] (Running) 


Mins. stam rs pane reer OAM Ther ra an 


WD UnsafeArrayList java te ArrayList.class 器 | {ib Thread.class fy AbstractList.class 


436- yax 
437 * Appends the specified element to the end of this list. 
438 * 
439 * @param e element to be appended to this list 
440 * @return <tt>true</tt> (as specified by {@link Collection#add}) 
441 27 
442- public boolean add(E e) { 
2. 443 ensureCapacityInternal(size + 1); // Increments modCount!! 
444 elementData[size++] =e; 在 这 于 停 下 
445 return true; 
446 


图 8.10 ”tl 线程 完成 容量 检查 


s 


RE, EtŠIITAŽZA, VEPRE, EtA addO KRN, 
成 进行 容量 检查 ， 如 图 8.11 所 示 。 


4 回 Bre [ava Application] 
a pp at localhost:5732 
4 of Thread [t2] (Suspenc 


= Thread.run( line: 745 
4 oP Thread [t1] (Suspended) 
E Arraylict<E>.edd(E) line: 444 
= UnsafeArrayList$AddTask.run( line: 19 
= Thread.run( line: 745 
p® Thread [t3] (Running) 
p® Thread [DestroyJavaVM] (Running) 


Mins to° Chee wen? 2° paneer er OAM Ther ra an 


QB) UnsafeArrayListjava fad Arraylist.class 器 hy Thread.class fa AbstractList.class 


容量 检查 完成 


此 时 ，tL 和 蕊 都 认为 ArrayList 中 的 容量 是 满足 它们 的 需求 的 ， 因 
此 ， 它 们 都 准备 开始 追加 元 素 。 让 我 们 先 选 择 t1， 完 成 追加 ， 如 图 8.12 
所 示 。 


$% Debug X 4 
4 O UnsafeArrayList [Java Application] 
4 & geym.conc.ch8.UnsafeArrayList at localhost:5732 
4 g® Thread [t2] (Suspended) 
= ArrayList<E>.add(E) line: 444 
UnsafeArrayList$AddTask.run(Q line: 19 
= Thread.run0O line: 745 
4 oD Thread [t1] (Suspended) 
= UnsateArrayList$AddTask.run(Q line: 19 
= Thread.run0 line: 745 
p® Thread [t3] (Running) 
p® Thread [DestroyJavaVM] (Running) 


Mose ‘Umm estes sane reer OAM Ther ra an 


JI) UnsafeArrayList.java foi ArrayList.class 33 | fy Thread.class foi) AbstractList.class 


436 yes 

437 * Appends the specified element to the end of this list. 

438 z 

439 * param e element to be appended to this list 

440 * @return <tt>true</tt> (as specified by {@link Collection#add} 
441 */ 

442- public boolean add(E e) { 


2 443 ensureCapacityInternal(size + 1); // Increments modCount!! 
444 elementData[size++] = e; 
AAG 


Alg.12 IZRABE 


在 革 追 加 完成 后 ， 世 并 不 知道 数据 空间 实际 上 已 经 用 完了 。 而 之 
前 的 容量 检查 告诉 t2， 你 可 以 继续 追加 元 素 ， 因 此 ，t2 还 会 义无反顾 
地 继续 执行 后 续 追 加 操作 。 选 择 t2， 计 t2 进 行 元素 追 加 ， 此 时 ， 当 2 试 
图 同 ArrayList 妃 加 元 素 时 ， 仍 加 操作 并 没有 如 我 们 预期 一 样 完成 ， 
为 ， 此 时 ，size 的 值 已 经 超过 了 elementData 的 边界 。 如 图 8.13 所 示 ， 可 
以 看 到 ArrayIndexOutOfBoundsException 异 常 位 于 t2 线 程 中 。 


东 Debug 2 475 Servers 
4 D UnsafeArrayList [Java Application] 
4 @& geym.conc.ch8.UnsafeArrayList at localhost:5732 


三 Thread.run0 line: 745 
4 o® Thread [t1] (Suspended) 
ArrayList<E>.add{(E) line: 445 
UnsafeArrayList$AddTask.run( line: 19 
= Thread.run( line: 745 
p® Thread [t3] (Running) 
»® Thread [DestroyJavaVM] (Running) 
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图 8.13 2AE 


让 t2 继 续 往 下 执行 的 结 采 就 是 前 文中 那 段 异常 信息 ， 
程 就 从 线程 列表 中 消失 了 (执行 结束 ) 。 


Lia: 


t2 线 


